Java virtual machine having integrated transaction management system

ABSTRACT

A computing system includes at least one computing device is configured to execute computer program instructions to accomplish a fully transactional application, including managed objects. The managed objects are persisted in a shared memory of the computing system, such that a scope of the objects is global to the transactional application. Operations on the managed objects are restricted to being carried out with respect to a transaction being processed by the fully transactional application. For example, the managed objects may be JAVA objects configured to be distributed such that the managed JAVA objects are accessible from at least one JAVA Virtual Machine (JVM).

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 USC 119(e) to U.S. provisionalpatent application No. 61/049,630, filed May 1, 2008, entitled “KTVMARCHITECTURE” (Attorney Docket KABIP004P) and to U.S. provisional patentapplication No. 61/101,967, filed Oct. 1, 2008, entitled “KTVMARCHITECTURE” (Attorney Docket KABIP004P2), all of which areincorporated by reference herein in their entirety.

BACKGROUND

The desire for high-volume, real-time transaction processingenvironments is well-known, for organizations such, as, stockbrokerages, credit card processing facilities and online reservationsystems. For example, from an operational point of view, “transactions”may include sales orders, credit card transactions or accounting journalentries. From a software point of view, transactions may include, forexample, database transactions of the sort that keep information in aconsistent form.

High-performance transaction processing used to be a rare phenomenon,utilized only in extreme environments by the largest companies. But inrecent years, the Internet has opened the door to the arrival of globalcustomers in quantity through e-commerce sites, call centers, and otherforms of direct interaction. Business-to-business relationships areintermediated by direct computer-to-computer interaction, frequentlybased on Web services. Content delivery and mediation for services musttake place in real-time. This bulge in transaction traffic follows thesame pattern that has transformed the telecommunications industry from afew providers of old-style, fixed local and long distance callingservices into a competitive field of real-time enterprises offeringwireless mobile plans for delivery of complex, combined data, voice andvideo content.

The requirements of global and real-time transaction processing arebecoming the norm, driving enterprises to seek out IT systems whosearchitectures can handle skyrocketing transaction volumes at the lowestpossible cost per transaction, in a manner that allows for flexibilityand agility in service offerings. Flexibility, high performance and lowcost constitute a new transaction-processing triangle that confoundssolutions and architectures designed on proprietary systems as recentlyas a decade ago.

One approach (which, while described here in the “Background,” is notadmitted to be prior art to the subject matter claimed herein) is atransaction processing development methodology employs a flexibletransaction processing development framework to facilitate developmentof a desired transaction processing application. See, for example, U.S.patent application Ser. No. 11/959,333, filed on Dec. 18, 2007 (AttyDocket No. KABIP002) and U.S. patent application Ser. No. 11/959,345,filed on Dec. 18, 2007 (Atty Docket No. KABIP003). Both application Ser.No. 11/959,333 and application Ser. No. 11/959,345 are incorporatedherein by reference in their entirety for all purposes.

In these patent applications, an example of a transaction processingdevelopment framework is described. In the described example, aplurality of service adaptors are provided. An infrastructure isprovided via which a user-defined business logic of the desiredtransaction processing application may be provided to the transactionprocessing development framework. The business logic definition isprocessed to instantiate the transaction processing application,including, instantiating a subset of the service adaptors to implementservices of the transaction processing application, and furtherincluding arranging the instantiated service adaptors to accomplish thebusiness logic in conjunction with generic transaction processing logic.The arrangement of service adaptors is guaranteed, when executed, toaccomplish the transaction processing application in a manner that isfully transactional.

SUMMARY

In accordance with an aspect, a computing system is provided in which atleast one computing device is configured to execute computer programinstructions to accomplish a fully transactional application, includingmanaged objects. In particular, the managed objects are persisted in ashared memory of the computing system, such that a scope of the objectsis global to the transactional application. Operations on the managedobjects are restricted to being carried out with respect to atransaction being processed by the fully transactional application. Forexample, the managed objects may be JAVA objects configured to bedistributed such that the managed JAVA objects are accessible from atleast one JAVA Virtual Machine (JVM).

In accordance with an aspect, a computing system is provided in which atleast one computing device is configured to execute computer programinstructions to accomplish a fully transactional application, includingmanaged objects. In particular, the managed objects are persisted in ashared memory of the computing system, such that a scope of the objectsis global to the transactional application. Operations on the managedobjects are restricted to being carried out with respect to atransaction being processed by the fully transactional application. Forexample, the managed objects may be JAVA objects configured to bedistributed such that the managed JAVA objects are accessible from atleast one JAVA Virtual Machine (JVM).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a basic environment architecture in one example.Referring to FIG. 1, the “external world” 102 interacts with aJAVA-enabled transaction platform service 104.

FIG. 2 shows an Order class that has its implementation installed on twonodes.

FIG. 3 illustrates an example in which each of six defined partitionsbelong to one of two partition groups, and each partition group supportsa range of partition numbers.

FIG. 4 illustrates an example in which synchronous updates cause objectdata to be copied to a backup, and any replicate, nodes in the sametransaction in which it is modified.

FIG. 5 illustrates an example in which deferred updates cause objectdata to be copied to a backup, and replicate, nodes based on aconfigurable time interval.

FIG. 6 illustrates an example of a configuration life cycle throughwhich configuration files can go.

FIG. 7 illustrates an example in which different class files areexecuted on each of a plurality of nodes.

FIG. 8 illustrates an example of an undetected deadlock between a JAVAmonitor and a transaction lock.

FIG. 9 is a sequence diagram illustrating rules to avoid transaction andmonitor deadlocks.

FIG. 10 illustrates an example of a Managed Object that is persisted inshared memory.

FIG. 11 illustrates an example of a string “name” being maintained on aprimary partition, a backup partition and a replica.

FIG. 12 illustrates an example of a development environment to developfully transactional applications using standard JAVA languageconstructs.

FIG. 13 illustrates an example of a service that includes a VM layer anda transaction processing layer.

FIG. 14 illustrates an example in which a development environment isintegrated to transaction processing, in which users are able to useJAVA development tools without modification, and the transparentintegration is a result, in part, of transaction bindings andenhancement of the JVM interpreter.

FIG. 15 illustrates an example of a slightly modified version of a JVMinterpreter that may be active during transaction execution forsubsequent transparent locking, deadlock detection, etc.

FIG. 16 illustrates functionality of an example of a transactionprocessing platform class loader.

FIG. 17 illustrates how an agent 1702 may manage server-sideresponsibilities of a remote development interface.

FIG. 18 illustrates a JAVA Bindings Adaptor (JBA) plugin to a designcenter, which enables transaction processing platform native componentsto be automatically accessible from JAVA programs.

DETAILED DESCRIPTION

The inventors have realized the desirability of allowing a user tospecify the user-defined business logic of a desired transactionprocessing application using a platform-independent language such asJAVA, even though JAVA (and other platform-independent languages)typically does not support fully-transactional applications. Inaccordance with an aspect, a JAVA Virtual Machine is interfaced to atransaction processing platform. Thus, for example, a transactionprocessing platform may be configured to execute instantiated serviceadaptors arranged to accomplish the business logic, provided in JAVA, inconjunction with generic transaction processing logic. The transactionprocessing platform may utilize a type system, and the type systemutilized by the transaction processing platform may be exposed to theJAVA code using JAVA bindings, such as using a simple programming modelto specify a JAVA class as a managed object. As a result, when executed,the user-defined business logic specified in JAVA and executed by a JAVAVirtual Machine (which may be, for example, a fully-certified JAVAVirtual Machine), enjoys all of the transaction processing features ofthe underlying transaction processing platform.

Before proceeding, we first provide a dictionary of acronyms andabbreviations used in this patent application. The “Kabira objectmodeling language” refers to a proprietary object modeling language (asopposed to JAVA, which is an open-source platform-independent language)usable to define business logic of a transaction processing application.

Dictionary of Acronyms and Abbreviations

Term Meaning BPMN Business Process Modeling Notation CORBA Common ObjectRequest Broker Architecture EJB Enterprise JAVA Bean IDL InterfaceDefinition Language IDLos Kabira object modeling language J2EE JAVA 2Enterprise Edition JAVA Object An object that is implemented using JAVA.JAR JAVA Archive JNI JAVA Native Interface JTA JAVA Transaction API JTSJAVA Transactional Service JVMTI JAVA Virtual Machine Tool Interface KCSKabira Configuration Service KPM Kabira Process Modeling KSSL KabiraSecurity Service Layer KTP Kabira Transaction Platform KTP Object Anobject that is implemented using IDLos. KTVM Kabira TransactionalVirtual Machine PHP Web scripting language RMI Remote Method InvocationTPP Transaction Processing Platform VM Virtual Machine

Furthermore, reference is made to the following documents:

-   -   The JAVA Virtual Machine Specification, Sun Micro Systems,        Second Edition, Tim Lindholm and Frank Yellin, 1999.    -   JVM Tool Interface, Sun Microsystems, Inc., Version 1.0, 2004.    -   JAVA Native Interface Specification, Sun Microsystems, Inc.,        Version 6.0, 2003.

In one example, a virtual machine is provided that is an enhancement toa standard transaction processing runtime environment (for example, atransaction processing runtime environment as described in the U.S.patent application Ser. No. 11/959,333 and 11/959,345 referred to aboveand incorporated herein by reference above), to support native executionof JAVA code in a fully transactional manner. In one example, thevirtual machine is implemented by a transactional processing platform(TPP) runtime being “embedded” into (or joined with) a standard (i.e.,standards-compliant) JAVA VM. As a result, the enterprise-classrobustness of the TPP is brought to JAVA applications. Basically, in theexample, programmers may use a standard JAVA programming model torealize sophisticated transactional features, without the addedcomplexity of having to code, embed frameworks, or integrate complexdisparate technologies to realize the transactional features.

In other words, a solution is provided in which main-frame classservices are tightly integrated into a JVM, which allows transactional,low-latency, highly available applications to be written with JAVA andresulting in what functions as a transactional JVM. This isaccomplished, in one example, using a simple programming model tospecify a JAVA class as a transactional system managed object. Suchmanaged objects provide, for example, transactions, distribution, sharedmemory persistence, high availability and/or replication. These featuresare described in detail throughout this patent application, but brieflytouched upon here.

With respect to transactions, all transactional system managed objectsare fully transactional, supporting such features as, for example,transactional locking, deadlock detection, and isolation. Moreparticularly, “fully transactional” means that the normal ACIDproperties of a transaction are preserved (Atomicity, Consistency,Isolation and Durability). With regard to atomicity, it is guaranteedthat all data and events are either committed or not. It is assured thatan event is delivered once and only once, as well as atomic datamodifications. With regard to consistency, data consistency within atransaction is guaranteed. For example, any constraint violation (e.g.deadlock) causes all data modifications to be rolled back and all eventsto be replayed. With regard to isolation, transaction isolation isprovided for multiple concurrent transactions. Multiple serializable and“dirty read” isolation semantics may be supported. With regard todurability, once a transaction commits, the results are committed tomemory.

In a high-availability configuration, the data may be committed tomemory on two machines transactionally. In some examples, single writer,multi-reader locking is also supported, with transparent lock promotion.Deadlock detection and retry may be transparently handled by thetransactional JVM. Transactional isolation ensures that object statemodifications are not visible outside of a transaction, until atransaction commits. Transactions may optionally span multiple JVM's,typically on different nodes of cooperating computing devices.Distributed locking and deadlock detection may be provided. Thetransactional JVM, in one example, provides all transactional featuresnatively, such that no external transaction manager or database isrequired.

Managed objects may be distributed, and a distributed managed object maysupport transparent remote method invocation and field access. Adistributed managed object may employ a single master node on which allbehavior is executed, and that also holds the master data for theobject. Generally, the managed objects may be held persistently in ashared memory. In this way, the object can live (e.g., be accessible,executed, etc.) beyond the lifetime of the JVM. In addition, sharedmemory objects may support extents.

A managed object may be mirrored, such that a mirrored managed objectmay have its object state transactionally copied from a primary node toanother node, such as a backup node, when the object is modified. Thebackup node may, for example, take up processing of the object when thenprimary node is offline. Support may be provided to restore the object'sstate from the backup node to the primary node during applicationexecution, without any service interruption. As a result, the managedobject may have high availability properties.

Mirrored managed objects may be contained in a partition, and one ormore partitions may exist on a single node. Each partition may beassociated with a primary node and a backup node. Partitions may bemigrated to different primary and backup nodes, during applicationexecution, without service interruption. This may include repartitioningthe managed objects to distribute the application load across differentnodes, without service interruption.

A timer service may be provided to support the objects transparentlyacross failover and restore operations. Object modifications may beoptionally written to a local file system on the primary or backupnodes, such as in a change log, to support both multi-node memory andfile system redundancy.

A replicated managed object may have its object state transactionallycopied to all configured nodes when the object is modified. A replicatedmanaged object also has a primary and backup node, which ensures thatthere is a backup node available for replicated object modifications inthe case of failure of the primary node.

The transactional JVM may be, in general, compliant withindustry-accepted JAVA specifications, such as being certified to beJAVA SE 6 compliant.

Having provided an overall introduction, we now provide a conceptualintroduction to technical concepts provided by examples of atransactional JVM. Later, we specify in greater detail how thesetechnical concepts may be realized in an embodiment.

As mentioned above, native JVM transactions may be provided for JAVAobjects by a transactional JVM, without requiring any databases ortransaction monitors. An atomic transaction may guarantee that a seriesof modifications to one or more objects either all occur (commit), orall do not occur (rollback). The state of the objects modified in thetransactions is guaranteed to be consistent once the transactioncompletes. Multiple transactions occurring on the same objects areisolated from each other through transactional locking. However, once atransaction completes, the changes are made durable to ensure that thetransactions can survive a system failure. These transactions arecharacterized by the well-known ACID principle (Atomic, Consistency,Isolation, Durability).

As also noted above, managed objects may have functionality appropriateto supporting fully transactional applications (and which functionality,in general, is not provided by conventional JVM's). In some examples,such functionality may be specified through the use of annotations,inheritance and configuration. In some examples, no special API's areneeded to convert a “Plain Old JAVA Object” (POJO) into atransactionally managed object. As such, developer productivity may beimproved, since developers may pay more attention to business logic andless attention to how that business logic may be implemented in a fullytransactional manner. For example, existing JAVA code may even besupported, greatly easing migration of such code to a fullytransactional environment.

Regarding distributed computing, it is noted that, during development,such objects may be restricted to being on one computing node and then,during deployment, the objects may be allowed to be distributed amongmultiple computing nodes. Mirrored objects may be associated with aPartition ID when created, where the Partition ID uniquely identifies aPartition that defines primary and backup nodes for the mirrored object.

In some examples, mirrored objects can only be created, updated anddeleted on the currently active node for the partition, and can be readon either the primary or backup node. The active node for a partition isthe configured primary node if the primary node is active, or is thebackup node if the primary node is not active.

A replicated managed object supports all of the behavior of a mirroredmanaged object, plus all the object state is copied to all nodes in acluster, so the replicated object state can be read on any node in thecluster. Mirrored objects are copied to only the backup node in acluster, whereas replicated objects are copied to more than one node(typically, all nodes) in a cluster

FIG. 1 illustrates a basic environment architecture in one example.Referring to FIG. 1, the “external world” 102 interacts with aJAVA-enabled transaction platform service 104. The service 104 is may beimplemented by one or more servers operating in concert, specificexamples of which are discussed in greater detail later. TheJAVA-enabled transaction platform service 104 includes a JAVAapplication 106, native JAVA skins 108 and a JAVA virtual machine 110. Atransaction processing platform 112 is interfaced to the JAVA virtualmachine 110 via a TP/JVM integration layer 114. Native services andchannels 116 of the transaction platform 112 are exposed to the JAVAvirtual machine as well.

With regard to the FIG. 1, the transaction platform 112 operates toprovide transactional processing, while the JAVA virtual machine 110 isbound to the transaction processing platform (and may be certified asmeeting an applicable JAVA standard). Thus, for example,high-availability and other transactional functionality may be providedfor applications written in the JAVA language, even existing JAVA codethat has not been particularly written with transactional functionalityin mind. For example, in-memory low latency transactional functionalitymay be automatically provided, as well as a high-availability (HA) auditlog option 119 to batch HA updates to databases such as provided byMySQL or Oracle. Failover and rapid fail-back functionality may also beprovided. Domain administration may be provided via a domain managerinterface 118 which may be accessible, for example, via HTTP using astandard web browser 120.

In the FIG. 1 environment, JAVA code automatically becomes inherentlytransactional and thus, for example, all aspects of local anddistributed HA transactions may be managed for what would otherwise bestandard JAVA objects In one example, the following “extends” constructresults in JAVA code being automatically transactional:

public classTransaction extends com.kabira.platform..Transaction {public Transaction.Result run( ** code here is automaticallytransactional)In accordance with an aspect, annotations may characterize a class'stransactional semantics. For example, in the following code sample, theclass “Pojo” (which stands for plain old JAVA object) inherently hastransactional properties. Isolation levels are granular to a per-fieldbasis, and transactionality is automatically bypassed for static fields.

import com.kabira.platform.annotation.*; @Transactional public classPojo { @Isolation (level = Isolation.Level.SERIALIZABLE) public longserializableField=0; @Isolation (level = Isolation.Level.TRANSIENT)public long transientField =0; public static long staticField = 0; }

We now describe a particular deployment model. In so describing theparticular deployment model, we treat a “machine” as a particularlocalized computing device, and a “node” as a particular transactionapplication administration or application server. A “cluster” is alogical grouping of nodes that communicate to support a distributedtransactional application. A “domain” is an administrative grouping ofnodes for management and development, and a “domain group” is a sub-setof nodes in a domain for management and development. One or more nodescan run on a single machine. A node can belong to one cluster, a nodecan belong to one or more domains, and a domain group can belong to onedomain. A cluster can be managed by more than one domain, and a clustercan also span one or more domain groups.

Now, as described above, managed objects are backed by shared memory.The managed objects can also be mirrored and replicated to other nodesin the cluster. In one example, the managed objects are not garbagecollected; they are only deleted when explicitly deleted by theapplication. Managed objects thus may exist even following a normal JVMor machine shutdown, as well as surviving node and machine failures ifthey are mirrored or replicated to another machine.

An extent is a collection of all instances of a managed object. Extentsare maintained for all managed objects. An extent can be used to findall instances of a managed object type at any time without having tomaintain the collection, such as by actively keeping track of all themanaged objects.

We now describe transaction functionality in more detail. For example,transactions can be local or distributed. Local transactions are used ona single node, even if the transactions span multiple JVM's on thesingle node. Distributed transactions are used between nodes. When atransaction spans nodes, a global transaction is started on the nodethat initiates the distributed work. The initiating node may act as thetransaction coordinator; there need not be a separate dedicatedtransaction coordinator. That is, each node may act as a transactioncoordinator for distributed work that the node initiates.

In some examples, there is no programmatic difference between local anddistributed transactions. An appropriate transaction type is initiatedtransparently depending on whether local or remote objects are in thetransaction. There may be a difference in how deadlocks are detectedwith local and distributed transactions, details of which are discussedlater.

Transaction locks are used to maintain data consistency. In someexamples, transaction locks are only taken on objects. A transactionlock is taken on an object when a transactional field is accessed ormodified. The transaction lock is released when the transaction commitsor rolls back. Executing a method on an object does not take atransaction lock (unless a transactional field is accessed in themethod). This implies that multiple threads can be executing the samemethod on the same object at the same time.

No transaction locks are taken on extents when objects are created ordeleted. This allows better parallelism for object creation anddeletion, but it does have implications to transactional isolation.Locking and isolation are described in greater detail later.

The transaction system may support multiple reader, single writer locks.For example, multiple concurrent transactions can read the same objectfields, but only a single transaction can modify an object field.

A read lock can be promoted to a write lock if an object field is read,and then the field is set. A read lock would be taken on the initialfield read and then promoted to a write lock when the field is written.If multiple transactions attempt to promote a read lock on the sameobject, all transactions but one will generate a “promotion deadlock.” Apromotion deadlock causes the transaction to rollback, dropping its readlocks. The transaction is then replayed causing the transaction toreacquire the object locks.

Distributed objects support the same locking paradigm as objects on thelocal node. However, data caching can affect the locking policy byaccessing the object data locally instead of from the remote node.Cached object data does not cause a distributed lock to occur. This cancause “state conflicts” if the object data is modified.

We now discuss deadlock detection. Since transactions are runningsimultaneously, it is possible to have deadlocks in applications.Deadlocks may be automatically detected and handled, such as in thefollowing manner. One transaction is chosen as the “winner” and allowedto complete, and the other deadlocked transactions are chosen as“victims,” which are rolled back to where they started and replayed.

Deadlock detection and resolution is transparent to the applicationprogrammer, but deadlocks are expensive in both responsiveness andmachine resources, so it is desirable to avoid deadlocks. Localtransactions detect deadlocks immediately in the execution path. Thereis no timeout value associated with local transactions.

Distributed transactions use a configurable time-out value to detectdeadlocks. If a lock cannot be obtained on a remote node within theconfigured time-out period, the distributed transaction is rolled back,releasing all locks. The transaction is then restarted. Becausedistributed deadlock detection is based on a time-out, applications withdistributed deadlocks may perform poorly because the configured time-outwould generally be large enough to ensure that no false deadlocks arereported during normal application processing.

Regarding isolation, transactions may support various isolation levelsfor object fields. One level is “none,” for which modifications arevisible outside of the current transaction before the transactioncommits. The serializable level is such that modifications are onlyvisible outside of the current transaction when it commits. Theisolation level of distributed objects can be affected by the configuredcache policy for the objects. With respect to extents, generally, oneisolation level is supported. For example, a read-committed extentisolation level is such that extent iterations and cardinality willreturn inconsistent results in the same transaction if othertransactions create or delete objects in an extent.

We now discuss transaction logging. To support rollback of atransaction, object modifications are logged. The logging mechanismtakes place in memory by keeping a copy of the “before image” of anychanges. Any object references that are no longer referenced in atransaction are protected from garbage collection so these referencesare still available if the current transaction rolls back.

If the current transaction commits, all logged data may be discarded andany reference locks to deleted objects may be released. If the currenttransaction rolls back, the original state of all objects is restored.Any objects created in the transaction are released to allow theseobjects to be garbage collected.

Regarding distributed computing, any managed object can be a distributedobject. A distributed object transparently provides remote methodinvocation and access to object fields across nodes. The fulltransactional guarantees for non-distributed objects are also true fordistributed objects.

Access to a distributed object is through a normal JAVA objectreference. In an example, all managed object references include data toidentify the node where the object was created. The same instance of anobject generally cannot exist on multiple nodes. Copies of an object'sstate may be located on multiple nodes to improve performance orrobustness, but the master copy is located on a single node—such as thenode where the object was created.

An object's behavior executes on the node where the object was created.Any methods invoked on an object reference are sent to the master nodeand executed there. Objects of the same type can be created on multiplenodes. This is accomplished by installing the application class files,or implementation, on multiple nodes. This application architecturesupports data partitioning and caching or service availabilitymechanisms.

FIG. 2 shows an Order class that has its implementation installed on twonodes—Node One and Node Two. Two instances of the Order class have beencreated, one on Node One and one on Node Two. When the Order.cancel( )method is executed on Node One, using the order(Node Two) instance, themethod is executed on Node Two. The opposite is true for the order(NodeOne) instance.

We now discuss location transparency. Location transparency is providedfor objects. This means that when an application accesses an object, thelocation of the object is transparent—it may be local or on a remotenode. Location transparency is accomplished through the use ofdistributed references. All created managed objects have a distributedreference that contains the location where the object was created.Operations invoked on an object are routed back to the location wherethe object was created and the operations executed on that node.

Fields are accessed on a local copy of the field data in memory. Everynode has both a location code and a node name. Location codes and nodenames are unique across all nodes in a cluster. The default locationinformation may be, for the location code, a hash of the node name. Forthe node name, the default value may be the local host name. Both ofthese defaults can be changed to allow multiple nodes to run on the samehost or to support a multi-homed host.

A location code may be a numeric identifier that is encoded in everyobject reference associated with managed objects. The location code canbe used to determine the actual network location of the object. Thelocation code of the node where the object was created is stored in theobject reference. A node name is a human-readable string associated withevery node. The node name is used to configure directed creates andHigh-Availability partitions.

Location discovery services provide support for runtime discovery oflocation information. This discovery may be utilized to allow nodes todiscover all other nodes along with their location information. Thelocation discovery service provides runtime mapping between a locationcode or node name and an actual network address. This mapping may bedone at runtime so network specific addresses do not need to be encodedin object references. The location discovery service may performlocation discovery in two ways: static discovery using configurationinformation; and dynamic discovery using a UDP broadcast protocol.

The system administrator can optionally configure the mapping between anode name and a location code/network address. This may be typicallyused if UDP broadcast cannot be used for location discovery. An exampleof when this may be used is when the remote node is across sub-netboundaries where broadcasts are not allowed.

If configuration information is not provided for a location name, UDPbroadcast may be used to perform dynamic location information discovery.This has an advantage that no configuration for remote nodes has to bedone on the local node—it is all discovered at runtime.

Location discovery is performed in at least the following cases: Adirected create to a remote node; and a method or field is set on aremote object. When an object type is defined to use directed create,the location on which the create should occur is specified using a nodename. When a create of this type is done, a location discovery requestis done by node name, to locate the network information associated withthe node name if the network information is not already known on thelocal node.

When an operation is dispatched on a remote object, a location discoveryrequest may be done by location code, to locate the network informationassociated with a location code, if the network information is notalready known on the local node.

We now discuss examples of types and type conflicts. Type informationfor every class installed on the local node may be broadcast to allother nodes when the local node starts up. As new types are added to thelocal node, their type information is broadcast to all other nodes inthe cluster.

When a node receives type information for a type that is not present onthe node, the node adds that type. When a node receives type informationthat is already present on the node, the node determines if the receivedtype information differs from the type information that is currentlyinstalled on the node. If the two types are the same, the node ignoresthe received type information. If the two types differ, informationabout the differences is stored in a type-mismatch table. Typemismatches can happen when different versions of the same type areinstalled on separate nodes.

Whenever data is marshaled for this type, either from the local node orwhen it is received from a remote node, the type mismatch table ischecked to see if the type matches using a type identifier and thelocation code of the remote node. If the type identifier/location codecombination is found in the type mismatch table, a type conflictexception will be raised and returned to the originator of the request.

We now discuss “directed creates.” As has been discussed earlier, thetransaction platform supports creating distributed objects on specificnodes. This allows an object creation to be done on any node in acluster and the create actually happens on a specific node that may notbe in the cluster on which the create was done.

The remote node does not need to have an implementation of the objectinstalled for directed create to operate properly. However, any attemptto execute behavior on the remote object may require the objectimplementation to be installed on the remote node.

In some examples, a Directed Create type cannot also be a Cache Grouptype. Cache groups provide support for pushing object state to a set ofnetwork nodes. This maintains a distributed extent for the type,providing a very simple mechanism to access distributed references on aremote node. More details of locating a remote object are discussedlater.

Nodes may be added to one or more cache groups by examining all types onthe local node and determining the cache groups for all of the installedtypes. This is the list of cache groups for which this nodeparticipates.

Cache groups may be automatically maintained. When a node is started, itfinds any other nodes that are part of any of its cache groups and pullsall references for those types to the local node. Once the node isinitialized the references are maintained by pushing updates to allnodes in the cache group as objects are created and deleted.

A node should have an implementation of the object installed to receiveupdates from other nodes. If a node does not have the implementationinstalled, the cache group update will not be performed and noreferences will be pushed to the node. A log message will be generatedindicating that a cache group is defined for the node, but noimplementation installed.

In some examples, a Cache Group type cannot also be a Directed Createtype.

Two distinct types of object data caching may be provided; passive, or“pull” caching, and active, or “push” caching. Passive caching copiesfield data to a remote node only when an object instance is accessed onthe remote node. Active caching automatically propagates all objectcreates, updates, and deletes to all remote nodes configured in a “cachegroup.”

Once data is cached on a remote node, the data is refreshed based on thecache policies described below. All field access is done using the localcached copy of data. This can avoid network I/O that may required byother distribution technologies to access object field data.

Modifications to an object's fields on a remote node are written back tothe node on which the object was originally created. The update happensin the same or a different transaction based on whether asynchronous orsynchronous transactionality is configured. Details of “asynchronous”vs. “synchronous” transactionality are discussed later.

Distributed types have a cache policy. The cache policy controls whencached data is considered stale and should be read from the node onwhich the object was created. In some examples, the following cachepolices can be defined for a type. These cache policies affect thebehavior of an object that is being accessed on a remote node. They donot affect the push caching done by a Cache Group. The master node foran object is the one on which it was originally created.

A “Never” cache policy means that the cached copy is always consideredstale. Every access to this object will cause the cached data to berefreshed. An “Always” cache policy means that the cached copy is alwaysconsidered valid. It is never refreshed. A “Once” cache policy meansthat the first time a reference is accessed, the cache is consideredstale. After that the cached copy is always considered valid. It isnever refreshed again. A “Timed” cache policy means that the cached copyis considered valid for a configured amount of time. The amount of timeafter which it is considered stale is controlled by a cache time. If theobject is accessed after cache time has expired since it was originallyread onto the node, it will be refreshed.

Types that are defined as part of a cache group should have a cachepolicy of Always. This is because any updates made to instances of thistype will be pushed out to all nodes in the cache group keeping the datain sync automatically. If the cache policy is not Always, remote nodecaches may cause unnecessary updates when an object is accessed.

Regarding asynchronous vs. synchronous, creates, writes, and deletes canbe configured to occur either asynchronously or synchronously withrespect to the transaction in which the create, write or deleteoccurred. If these operations are configured to occur asynchronously,they will occur in a separate transaction on the remote node than theydid on the local node. This implies that there may be data inconsistencybetween the two nodes for a period of time. There are no distributedlocks taken on remote nodes.

If these operations are defined to occur synchronously, they will occurin the same transaction on the remote node as they did on the localnode. This implies that there is always data consistency between tworemote nodes. Distributed locks are taken on the remote node to ensurethe data consistency.

Regarding distributed computing, asynchronous operations may improve theoverall performance of a distributed system because no remote locks areheld. They also avoid the overhead associated with a distributedtransaction. A downside is that there can be data inconsistency in adistributed system at a given point in time. This inconsistency lastsuntil the asynchronous work is executed on the target node.

Asynchronous creates cause an object to be created in a separatetransaction on a remote node. Because the create is done in a separatetransaction on the remote node, the transaction system does not report aduplicate key error back to the node on which the object was created. Ifa duplicate key is detected on the remote node, the create is notperformed and a warning message is logged.

Regarding reading and writing data, object field data is transparentlyread from and written to a remote node when field data is accessed on alocal node based on the caching policy.

Read operations are dispatched to a remote node to read field datadepending on whether the cached data on the local node is stale. If thelocal cache is stale, a read will be done when a field is accessed. Theread operation will complete before the get of the field data returns tothe caller. All reads are done on the remote node in the sametransaction in which the field access occurs—in other words, the readsexecute synchronously.

When a field associated with a remote object is modified on a localnode, a write is dispatched to the remote node to update the field dataon that node. This write can occur in the same, or a differenttransaction depending on whether writes are defined to executeasynchronously or synchronously for the type. If writes are defined tobe performed asynchronously for a type, it is possible that the targetobject of the write on the remote node has been deleted. This error isdetected and the write is discarded. A warning message is logged.

A state conflict is reported when a write operation from a remote nodedetects that the data on the local node has changed underneath it. Thisis possible in a distributed system because the object may be modifiedfrom multiple nodes in the system.

State conflicts may be handled differently depending on whether writesare configured to be executed asynchronously or synchronously. Whenwrites are configured to execute asynchronously, the state conflict isnot detected until the write is executed on the remote node. This is ina different transaction than the one that modified the object data. If astate conflict is detected, the data is discarded. A warning message islogged.

When writes are configured to execute synchronously, state conflicts arehandled transparently. If a state conflict is detected on the remotenode, an error is returned to the local node, where the cache isflushed. The transaction will be rolled back and replayed. Theapplication is never aware that a state conflict occurred.

Extents have a cache policy of Always. When an extent is accessed, onlyobject references on the local node are returned. References are in thelocal extent either because the object was created on the local node, orit was pushed to the local node because the node is part of a cachegroup and references are being pushed to the node.

We now discuss an overview of failure conditions (abandoned transactionhandling). Transactions can only be committed or rolled back by theinitiator of the transaction. This means that any global transactionexecuting on a remote node cannot commit or roll back until the nodeinitiating the transaction explicitly indicates that this should happen.

In normal operation, this generally works well. However, in the casewhere a node that initiated a global transaction fails, the transactionwill remain pending on all remote nodes until the initiating node isrestarted. If the initiating node never restarts, then the transactionis abandoned. Abandoned transactions generally require operatorinteraction to determine the outcome and complete the transaction.

We now discuss high-availability (HA). An HA node is a node that isconfigured for the HA service. An HA node may be in one of four HAstates. An “unknown” HA state means that the node is started but the HAconfiguration has not been loaded. An “inactive” HA state means that theHA configuration is loaded, but HA has not been enabled. An “active” HAstate means that the HA state is enabled and active. Finally, a “down”HA state means that connectivity has been lost to the node. The downstate will generally only be seen for remote nodes. A local node willnot see itself in the down state. A node in an Active state can receiverequests from a router (details of which are discussed later), create,modify and delete Mirrored and Replicated Managed Objects.

A node in an Unknown state functions as a non-HA node. An Unknown stateimplies that the node has not been configured for HA. The HA router willonly route to the local node. Mirrored and Replicated Managed Objectscan be created, modified or deleted, but the changes are not propagatedto other nodes

A node in an Inactive state does not receive requests from an HA routerbut it can route to other nodes. This is normal operation when a node isrecovering from a failure. An Inactive node does not create, modify, ordelete Mirrored or Replicated Managed. The Mirrored and ReplicatedManaged Objects are hosted on a backup node if the backup node isActive.

When a node is restarted, it is in an Inactive state. A restore nodecommand is used to restore the node to Active.

Regarding mirrored and replicated managed objects, mirrored managedobjects have a copy of the object state transparently maintained on abackup node. Mirrored managed objects can be updated on the currentactive node—either the primary or the backup if the primary node isunavailable. Replicated managed objects have a copy of the object statetransparently maintained on a backup node. They also have the objectstate copied to all nodes in the cluster. Replicated Managed Objects areonly updated on the current active node—either the primary or the backupnode if the primary node is unavailable.

Regarding partitions, to balance an application workload across multiplemachines, application data may be organized into partitions. Eachmirrored and replicated managed object is in a single partition. When anobject is created, an application assigned partition identifier for anobject defines what partition contains the object. A partitionidentifier includes a group name and a number.

A partition is identified by a name. Partition names are globally uniqueon all nodes in the cluster. A partition group is a set of partitionsthat all have the same group name. The range of partition numberssupported by a partition group is from zero to the maximum partitionnumber defined for all partitions in the group.

Partition numbers should not overlap for partitions in the samepartition group, and the range of partition numbers should cover theentire range of possible partition number values, from zero to themaximum partition number. A partition identifier uniquely identifies itsassociated partition by a partition group name and a partition numberfalling within the range of partition numbers for a specific partition.

In the example shown in FIG. 3, six defined partitions are named Onethrough Six. There are two partition groups defined—A and B. Eachpartition group supports a range of partition numbers from zero to 30. Apartition identifier that has a group of A and a number of 22 maps topartition Three. Partitions are defined using configuration tools. Thesame partition configuration is loaded on all nodes for correctoperation.

A node can support one or more partitions. All partitions generally havea primary and a backup node defined. If the primary node fails, thebackup node takes over maintaining the object state for the primarynode. When the primary node is brought back online, it is restored fromthe backup node. Backup nodes can also be taken offline and restoredfrom a primary node.

Partition States (Partitions can have a state as shown in the tablebelow):

HostedOnPrimary The partition is active on the primary nodeHostedOnBackup Partition is active on backup node. Migrating Partitionis migrating to another node RestoringPrimary Partition is beingrestored on primary. State only seen on backup node RestoringBackupPartition is being restored on backup. State only seen on primary nodePrimaryBeingRestored Partition is being restored on primary. State onlyseen on primary node BackupBeingRestored Partition is being restored onbackup. State only seen on backup node. Abandoned Partition not activeon any node. Both primary and backup nodes for partition areunavailable.

Mirrored and Replicated Managed Objects can be copied to remote nodeseither synchronously or deferred. As shown in FIG. 4, synchronousupdates cause the object data to be copied to a backup, and anyreplicate, nodes in the same transaction in which it is modified. Theobject data is copied to the backup node when the current transactioncommits. Multiple updates to the same object in the same transactionwill result in only a single update to the remote nodes. Synchronouscopies ensure that no data is lost during failures at the cost ofnetwork latency in the application transaction path.

As shown in FIG. 5, deferred updates cause the object data to be copiedto a backup node and to any replicate nodes, based on a configurabletime interval. Objects are copied to remote nodes in a differenttransaction than the one in which they were modified. Deferred updatesexpose the application to data loss during failures, but it removes thenetwork latency in the application transaction path.

When a node in an HA cluster is to be brought back online following afailure or system maintenance, the node is restored. A node restoreperforms the actions of copying mirrored object data to the node for allpartitions hosted on the node, and copying all replicated object data tothe node. When all of the object data copies complete, all partitionsthat have this node as a primary are changed to active on this node. Thenode state is than changed to Active and normal HA processing starts.

Regarding migration of a partition, partitions support migration todifferent primary and backup nodes without requiring system downtime.Partition migration is initiated by updating the configuration on thecurrent primary node for the partition.

When the updated configuration is loaded and activated on the primary,all object data in the partition is copied to the new primary and/orbackup node. When the copy completes, the partition state is changed toindicate that the partition is now active on the new node(s). The objectdata is deleted on the node from which the partition moved.

The partition state changes from HostedOnPrimary to Migrating when theconfiguration is activated on the primary node. When the migration iscomplete, the partition state is HostedOnPrimary again. Once thepartition migration completes, the updated HA configuration file shouldbe loaded on all other nodes in the HA cluster.

Regarding routing, transparent routing of data across nodes is provided.Routing to a specific partition or node is supported. When routing to apartition, the data is sent to the currently active node for thepartition. This may be the primary node, or the backup node if theprimary node is offline. Routing may be used for a number of reasons,including ensuring that all Mirrored and Replicated Managed Objectupdates occur on the active node for the object. Routing may also beused to send data to a specific node that has connectivity to anexternal client or system. Routing may also be used for otherapplication specific reasons. Any JAVA object that is serializable canbe routed.

Regarding configuration, online versioning of configuration data issupported. This allows the configuration to change without impacting arunning application.

In some examples, configuration files contain the following items:

-   -   Name—user define name.    -   Version—version number of configuration file    -   Type—type of configuration data

For example:

// // This file defines version 1.0 of a distribution configurationnamed myconfiguration // configuration “myconfiguration” version “1.0”type “distribution” {   ... };

Configuration files can go through a configuration life cycle as shownin FIG. 6. For example, possible states are:

-   -   Loaded—configuration data has been loaded into a node. This is a        transient state. The configuration data automatically        transitions to the Inactive state once it has been successfully        loaded.    -   Inactive—configuration data is loaded into a node, but it is not        the active version.    -   Active—the configuration version is active.    -   Removed—configuration data has been removed from the node. This        is a transient state.

Only one active version is generally allowed for each configuration Namewithin a type. For example if there are two versions, version 1.0 andversion 2.0, of a configuration file with a Name value of“myconfiguration” and a type of distribution, only one version is activeat a time in a node.

An audit step occurs before any configuration data changes states toensure that the configuration data does not cause runtime failures. Ifthe audit fails, the configuration state change does not occur and thesystem is left in the previous known good state.

When one version of a Name is active, and a new version is activated,the old version is replaced. That is, the old version is deactivated andthe new version is activated as a single transaction. For example,loading and activating version 2.0 to replace version 1.0 may take placeas follows:

1. Configuration “myconfiguration” version 1.0 is active.

2. Configuration “myconfiguration” version 2.0 is loaded, passes audit,and is activated.

3. Configuration “myconfiguration” version 1.0 is now inactive, andconfiguration “myconfiguration” version 2.0 is active.

Because the configuration replacement is done in a single transaction,there is no disruption to a running application.

Deactivating a configuration version does not restore any previouslyactive version. Another version is activated, or loaded and activated,as a separate step. (Until this is done, there is no active version.)Nor does deactivating a version unload it; it must be explicitly removedto achieve this. Until removed, a deactivated version remains availableto be reactivated again without having to reload the configuration data.

Having described some basics of distributed JAVA transactionalapplications, we now describe a methodology to developing suchdistributed applications using the transaction platform. Distributedapplications may be developed using standard JAVA development tools, andthe deployment and execution of the thus-developed applications aretransparently managed on multiple nodes.

For example, features provided to support distributed applicationdevelopment are:

-   -   deploying applications to one or more nodes in an application        domain.    -   partitioning applications using domain groups within an        application domain.    -   dynamically adding a node to an application domain.    -   automatically restoring an application to a node that is        restarted in an application domain.    -   application output available in the development tool for all        application nodes.

Distributed development of applications, in one example, utilizes aDomain Manager node to coordinate the deployment and execution ofapplications to multiple nodes. To support distributed development, adeployment tool may be configured to connect to a Domain Manager node.The Domain Manager node coordinates all communication to the applicationnodes.

When an application is executed, the main entry point for theapplication is loaded and executed on all target nodes for theapplication. The same application is loaded on all application nodes. Ifthe application requires different behavior on different nodes,application logic should provide this alternative behavior. Once “main”is started on each application node, each node requests class files asneeded based on application execution. This implies that different classfiles are executed on each node. The standard class resolution rules areused to locate class files, as described in detail later.

For example, in FIG. 7, Node A requests class X from the client, node Brequests class Y, and node C requests class Z. The Domain Managermonitors the execution of the application on all nodes. The deploymenttool runs until all application nodes exit. Individual nodes can exit,and new ones can join the distributed application while the program isbeing executed.

The application execution scope may be controlled using these DeploymentTool parameters:

-   -   domainname—execute the application main on all nodes in the        domain.    -   domaingroup—execute the application main on all nodes in a        domain group.    -   domainnode—execute the application main on a single node.

For example using FIG. 7, the parameters may be:

-   -   domainname=MyDomain—executes main on Node A, Node B, and Node C.    -   domaingroup=MyGroup—executes main on Node A and Node B.    -   domainnode=Node C—execute mains on node C only.

As an illustration, the example below is run twice—once withdomainname=Fluency Development and once with domainnode=primary, and theresults are shown.

Distributed Development // DESCRIPTION // snippet to show execution onmultiple nodes // // TARGET NODES // //  domainname = FluencyDevelopment //  domainnode = primary packageprogramming.fluency.development; public class A {   public static voidmain (String [ ] args)   {     System.out.println(“Welcome to Fluency”);  } }

Here is the output using domainname=Fluency Development.

[replica] Listening for transport dt_socket at address: 33959 [backup]Listening for transport dt_socket at address: 42952 [primary] Listeningfor transport dt_socket at address: 62361 [replica] Welcome to Fluency[backup] Welcome to Fluency [primary] Welcome to Fluency INFO:Application [programming.fluency.development.A1]  running on node[replica] exited with status [0] INFO: Application[programming.fluency.development.A1]  running on node [backup] exitedwith status [0] INFO: Application [programming.fluency.development.A1] running on node [primary] exited with status [0] INFO: Run ofdistributed application [programming.fluency.development.A1] complete.Here is the output using domainnode = primary. [primary] Welcome toFluency INFO: Application [programming.fluency.development.A2]  runningon node [primary] exited with status [0] INFO: Run of distributedapplication [programming.fluency.development.A2] complete.

When a new node joins a domain that is currently executing anapplication, the application is deployed to the new node transparently.Any application data required for that node should be either replicatedor mirrored managed objects, so that the data is available on the newnode.

A node can remove itself from the distributed application by leaving thedomain. A node can leave a domain because it is shutdown, it is in anerror condition, or it is explicitly removed from a domain. Thedeployment tool is notified that a node left the distributedapplication; however, execution continues. A node that removed itselffrom a distributed application can rejoin the distributed application byjoining the domain again. When the node is active in the domain again,it is treated the same as a new node being added to the domain.

Regarding debugging, a JAVA debugger can be remotely attached to any ofthe application nodes participating in a distributed application. Thefollowing Deployment Tool parameters are examples of parameters that canbe used to control debugging of distributed applications:

-   -   remotedebug—enable remote debug port on all target application        nodes.    -   suspend—suspend all target application nodes before executing        main.

When using suspend to control execution of main on target applicationnodes, the debugger should be connected to each application node tocontinue application execution. In an example, if the debugger is notconnected to an application node, the application will never continueexecuting on that node.

The output below shows what may be displayed when an application isdeployed to a node (annotation added):

INFO: fluency.jar version: [core_linux080924] INFO: Kabira DomainManager version: [core_linux080924] INFO: node [replica] version:[core_linux080924] # # This is the requested debugger port on thereplica node # INFO: node [replica] JVM remote debugger agent listeningon port [48072] ... INFO: node [backup] version: [core_linux080924] # #This is the requested debugger port on the backup node # INFO: node[backup] JVM remote debugger agent listening on port [2471] ... INFO:node [primary] version: [core_linux080924] # # This is the requesteddebugger port on the primary node # INFO: node [primary] JVM remotedebugger agent listening on port [9738] ... # # These are the messagesfrom the JVM confirming the debugger # port on all nodes # [replica]Listening for transport dt_socket at address: 48072 [backup] Listeningfor transport dt_socket at address: 2471 [primary] Listening fortransport dt_socket at address: 9738

We now describe details of a transaction processing JAVA Virtual Machineand its life cycle. Regarding starting and stopping, when a transactionprocessing JVM is first started, it executes the application's mainentry point, passing in any specified application parameters. When themain method returns, the JVM exits. The following is a simplisticexample of the entry and exit point in JVM source code.

package programming.fluency.jvmlifecycle; public class A { public staticvoid main(String[ ] args) { // // Returning from main - causes the JVMto exit // System.out.println(“returning from main”); } }

In the example, when main exits, the JVM is shut down. The node waitsfor a configurable amount of time before forcing down the JVM. If thenode has to force down the JVM, the node must be restarted to be usedagain. The usual reason that a JVM will not exit is that the applicationstarted threads that do not exit when the JVM is asked to shutdown.

A transactional JVM can also be shutdown by an operator command externalto the application. The application can detect the operator command andexit from main when the command is detected. An example of such shutdownis provided in the following example.

package programming.fluency.vmlifecycle; importcom.kabira.platform.swbuiltin.*; import com.kabira.platform.Transaction;public class E extends Transaction {   private boolean m_exit = false;  public static void main (String [ ] args) throws InterruptedException  {     E  e = new E( );     while (e.m_exit == false)     {      e.execute( );       System.out.println(“waiting for operator toshutdown       JVM...”);       Thread.sleep(4000);   }  System.out.println(“Operator shutdown JVM exiting”);   //   // Returnfrom main shutting down the JVM   //   }   @Override   protected voidrun( ) throws Rollback   {   m_exit = EngineServices.isStopping( );   }}

When the preceding example is run, it outputs the following (annotationadded):

# # Waiting for node to shutdown # waiting for operator to shutdownJVM... waiting for operator to shutdown JVM... waiting for operator toshutdown JVM... waiting for operator to shutdown JVM... waiting foroperator to shutdown JVM... waiting for operator to shutdown JVM...waiting for operator to shutdown JVM... waiting for operator to shutdownJVM... # # Node is shutdown. An error is seen since communication was #lost to the node from the client when the node shuts down. # This is theexpected behavior. # # NOTE: The “Operator shutdown JVM exiting” messageis not printed # because the node shutdowns before the message is seenby the # deployment tool. # Error: [39] : Node cannot performadministration commands. Reason: switch not started (switchadminnotifier not available). FATAL: Command failed: null

We now describe managing threads. In particular, in order to cleanlyshutdown the JVM, all user created threads should exit when mainreturns. The following approaches may be used to manage user threads toensure a clean JVM shutdown:

1. Do not return from main until all user threads exit.

2. Use a JVM shutdown hook to determine when to exit user threads.

3. Mark all user threads as daemon threads.

The example below shows the use of Threadjoin( ) to block in main untilthe user thread exits.

package programming.fluency.vmlifecycle; class T extends Thread {  @Override   public void run( )   {     System.out.println(“hello fromthe thread”);   }   } public class B   {     public static voidmain(String[ ] args)   {   //   // Create and start a new thread   //  T  t = new T( );     t.run( );     //     // Wait for the thread toreturn before exiting main     //     try     {       t.join( );     }    catch (InterruptedException ex)     {       // handle interruptedexception     }     //     // Returning from main - causes the JVM toexit     //     System.out.println(“returning from main”);   } }

The example below shows the use of a JVM shutdown hook to coordinateshutdown of user threads.

package programming.fluency.vmlifecycle; // // This is the user thread// class T extends Thread {  volatile boolean done = false; @Override public void run( )  {   while (done == false)   {    try    {    System.out.println(“thread sleeping...”);     Thread.sleep(4000);   }    catch (InterruptedException ex)    {     // Handle exception   }   }  } } // // This is the shutdown hook thread // class S extendsThread {  S(T t)  {   m_t = t;  }  private T m_t;  @Override  publicvoid run( )  {   System.out.println(“VM shutting down”);   m_t.done =true;  } } public class D {  public static void main(String[ ] args)  {  //   // Create a thread   //   T  t = new T( );   //   // Set up ashutdown hook   //   S  s = new S(t);   Runtime.getRuntime().addShutdownHook(s);   //   // Start the user thread   //   t.start( );  //   // Return from main - causes the JVM to call the   // installedshutdown hook and to exit the JVM   //   System.out.println(“returningfrom main”);  } }

The example below shows how a thread can be marked as a daemon thread.Daemon threads allow the JVM to exit even if they are running.

package programming.fluency.vmlifecycle; class T extends Thread { @Override  public void run( )  {   try   {   System.out.println(“thread sleeping...”);    Thread.sleep(5000);   }  catch (InterruptedException ex)   {    // Handle exception   }  } }public class C {  public static void main(String[ ] args)  {   //   //Create a new thread   //   T t = new T( );   //   // Mark the thread asa daemon thread   //   t.setDaemon(true);   //   // Start the thread  //   t.run( );   //   // Returning from main - causes the JVM to exit  //   System.out.println(“returning from main”);  } }

Regarding unhandled exceptions, unhandled exceptions cause the currentthread to exit. If the current thread is the thread in which main wasexecuted, the JVM will exit with a non-zero exit code. The example belowshows an unhandled exception in the main thread.

package programming.fluency.vmlifecycle; class UnhandledExceptionextends JAVA.lang.Error { } public class A {  public static void main(String [ ] args)  {   //   // Throw an unhandled exception - non-zero  exit code returned from main   //   throw new UnhandledException( ); } }

When the above example is run, the following output may be generated:

[primary] Listening for transport dt_socket at address: 50647 [primary]JAVA main class programming.fluency.vmlifecycle.A.main exited with anexception. [primary] JAVA exception occurred:programming.fluency.vmlifecycle.UnhandledException [primary] atprogramming.fluency.vmlifecycle.A.main(A.JAVA:30) INFO: Application[programming.fluency.vmlifecycle.A2] running on node [primary] exitedwith status [−1] INFO: Run of distributed application[programming.fluency.vmlifecycle.A2] complete.

Transactional behavior is optionally provided for any JAVA class.Transaction boundaries may be defined using, in an exampleimplementation, the com.kabira.platform.Transaction class. Annotation isused to specify which classes are transactional.

An example of a transaction class is show below:

package com.kabira.platform; public abstract class Transaction {  /**  *Possible returns from the execute( ) method.  */  public enum Result  {  /** Commit the transaction */   COMMIT,   /** Rollback the transaction*/   ROLLBACK  }  /**  * Exception thrown if execute( ) is called with atransaction  * already active, or the transaction services are not  *available.  */  public static class InvalidTransactionState extendsJAVA.lang.Error  {   InvalidTransactionState(String message)   {   super(message);   }  }  /**  * Exception thrown in the run method torollback the transaction  */  public static class Rollback extendsJAVA.lang.Exception  {   public Rollback( )   {    super(“no message”);  }   public Rollback(String message)   {    super(message);   }  } public Transaction( ) { }  /**  * User defined method that is run inthe context of a transaction.  *  * @exceptioncom.kabira.platform.Transaction.Rollback  * Thrown if the transactionshould be rolled back  * and all changes discarded.  */  protectedabstract void run( ) throws Transaction.Rollback;  /**  * Executes theuser defined run( ) method within a transaction. Any  * deadlocks willbe transparently retried.  *  * @throws InvalidTransactionState  * If atransaction already active, or the transaction services  * are notavailable.  */  public final Result execute( ) throwsInvalidTransactionState  {  ...  } }

An application may implement the abstract run method to executeapplication code in a transaction. A transaction is implicitly startedwhen the execute method is called. The execute method calls theapplication-provided run method and executes the application code in atransaction. A transaction may be terminated in the following ways:

-   -   application code returns from the run method    -   application throws a Transaction.Rollback exception from the run        method    -   a deadlock is detected (the transaction is transparently        replayed)    -   an unhandled exception

An application can explicitly control the outcome of a transaction bythrowing the Transaction.Rollback exception in the run method. TheTransaction.Rollback exception causes the current transaction torollback. Returning normally from the run method causes the transactionto commit.

The following example is a simple counting program that demonstrates afield value being rolled back.

package programming.fluency.transactions; importcom.kabira.platform.Transaction; public class T extends Transaction { private boolean m_commit;  private int m_count = 0;  public static voidmain (String [ ] args)  {   T  t = new T( );   t.m_commit = true;  t.execute( );   System.out.println(t.m_count);   t.m_commit = true;  t.execute( );   System.out.println(t.m_count);   t.m_commit = false;  t.execute( );   System.out.println(t.m_count);   }   @Override  publicvoid run( ) throws Transaction.Rollback  {   m_count += 1;   if(m_commit == true)   {   return;   }   throw new Transaction.Rollback();  } }

When the above example is executed, the output may be (annotationadded):

# # Initial call to execute that commits # 1 # # Second call to executethat commits # 2 # # Third call to execute that rolls back - fieldrestored to value before call # 2

In some examples, a JAVA class may be made transactional in thefollowing ways:

-   -   it has an @Transactional annotation    -   it extends a transactional class    -   it is contained by a transactional class

All fields in a transactional class are transactional unless explicitlychanged using the @Isolation annotation (described below). Thisexplicitly includes:

-   -   primitive types    -   object references    -   array references

Field modifications using a reference in a transactional field aretransactional, while modifications using a reference in anon-transactional field are non-transactional.

We now describe the “@Transactional” annotation in accordance with someexamples of a transactional JAVA VM. The @Transactional annotation marksa JAVA class as transactional. When an instance of a JAVA class with the@Transactional annotation is created, read, modified, or deleted in atransaction, it has transactional behavior. The @Transactionalannotation may be defined as shown below:

package com.kabira.platform.annotation; import JAVA.lang.annotation.*;/** * Mark a class transactional */ @Documented @Inherited@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) public@interface Transactional {  /**  * Define the transaction context for aclass  */  public static enum Context  {   /** a transaction is requiredto use type */   REQUIRED,   /** type can be used with or without atransaction */   OPTIONAL,  }  Context context( ) defaultContext.OPTIONAL;  /**  * Define whether inherited fields are excludedfrom  */  public static enum InheritedFields  {   /**   * Inheritedfields are not transactional   */   EXCLUDE,   /**   * Inherited fieldsare transactional   */   INCLUDE,  }  InheritedFields inheritedFields( )default InheritedFields.INCLUDE; }

The following table summarizes some @Transactional Annotation Properties

Property Values Comments Context REQUIRED - class instances The Contextproperty defines can only be created, read, whether a transaction ismodified, or deleted in a required for instances of a transaction.OPTIONAL - class. All managed objects class instances can optionallyhave a REQUIRED be in a transaction when transaction context. instancesare created, read, modified, or deleted. Inherited EXCLUDE - allinherited The InheritedFields property Fields fields are not included incontrols whether inherited transactional behavior. fields are includedor INCLUDE - all inherited excluded from transactional fields areincluded in behavior transactional behavior.

Attempting to create, read, modify, or delete an instance of aContext.REQUIRED class outside of a transaction will cause acom.kabira.platform.NoTransactionError to be thrown by the JVM.

All object and array references are implicitly annotated with@Transactional(Context.OPTIONAL).

Transactionality is propagated to contained references in atransactional class. This applies to both object and array references.

The @Isolation annotation controls the transaction isolation of fields.When a field with the @Isolation annotation in an instance of a JAVAclass is read or modified in a transaction, it uses the isolation leveldefined by the @Isolation annotation. The @Isolation annotation may bedefined as shown in the following example:

package com.kabira.platform.annotation; import JAVA.lang.annotation.*;/** * Define the transaction isolation of a field */ @Documented@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.FIELD) public@interface Isolation {  /**  * Define isolation level  */  public staticenum Level  {   /** the field uses a serializable isolation level */  SERIALIZABLE,   /** field is non-transactional */   TRANSIENT  } Level level( ) default Level.SERIALIZABLE; }

An @Isolation Annotation property includes the “level” field taking thevalue “SERIALIZABLE,” which indicates a single write, multi-readerlocking is used for the field; or taking the value “TRANSIENT,” whichindicates no transactional locking or logging is used for the field.

We now discuss annotation audits. When a class is loaded into thetransactional JVM, the Class Loader performs the following annotationaudits:

-   -   The @Transactional Context property cannot be OPTIONAL if a        class extends a superclass with an @Tranasactional Context of        REQUIRED. It is illegal to relax transactional requirements in        an inheritance hierarchy.    -   The @Transactional InheritedFields property cannot be EXCLUDE if        the class extends a super-class with an @Transactional        annotation.    -   The @Isolation annotation cannot be specified on a static field.    -   The @Isolation Level property cannot be specified as TRANSIENT        on a field in a Managed Object class (described later).

When an audit failure occurs, as illustrated in the following example,the class is not loaded and an audit failure message is reported.

package programming.fluency.transactions; importcom.kabira.platform.annotation.*; importcom.kabira.platform.Transaction; importcom.kabira.platform.ManagedObject; // //  Cannot relax transactionalrequirements // @Transactional(context=Transactional.Context.OPTIONAL)class C1 extends ManagedObject { }; public class C extends Transaction { public static void main (String [ ] args)  {   new C( ).execute( );  } @Override  protected void run( ) throws Rollback  {  //  // This classwill fail annotation audit and fail to load  //  new C1( );  } }

When this above example is executed, the following may be output:

[primary] Listening for transport dt_socket at address: 45314 [primary]Class programming.fluency.transactions.C1 failed audit; [Cannot defineTransactional context to be Optional if the superclass defines itRequired.] [primary] JAVA main classprogramming.fluency.transactions.C.main exited with an exception.[primary] JAVA exception occurred: JAVA.lang.NoClassDefFoundError:programming/fluency/transactions/C1 [primary] atprogramming.fluency.transactions.C.run(C.JAVA:42) [primary] atcom.kabira.platform.Transaction.execute(Transaction.JAVA:132) [primary]at programming.fluency.transactions.C.main(C.JAVA:33) INFO: Application[programming.fluency.transactions.C0] running on node [primary] exitedwith status [−1] INFO: Run of distributed application[programming.fluency.transactions.C0] complete.

The example below illustrates:

-   -   use of the @Transactional annotation    -   use of the @Isolation annotation    -   behavior of the Transactional.InheritedFields.EXCLUDE property        value    -   inheriting transactional behavior through extends

package programming.fluency.transactions; importcom.kabira.platform.annotation.*; importcom.kabira.platform.Transaction; class A1 {  String s; } // // Thisclass must execute in a transaction // @Transactional( context=Transactional.Context.REQUIRED, inheritedFields=Transactional.InheritedFields.EXCLUDE) class A2 extendsA1 {  String t;  @Isolation(level=Isolation.Level.TRANSIENT)  String u;} // // This class is transactional because it extends A2 // class A3extends A2 {  String v; } public class A extends Transaction {  publicstatic void main (String [ ] args)  {   new A( ).execute( );  } @Override  protected void run( ) throws Rollback  {   A3 a3 = new A3();   //   // This is not transactional since inheritedFields   //property is EXCLUDE   //   a3.s = “s value”;   //   // This istransactional   //   a3.t = “t value”;   //   // This is nottransactional because of @Isolation annotation   //   a3.u = “u value”;  //   // This is transactional   //   a3.v = “v value”;  } }

Regarding static fields, static fields are always non-transactional. Theexample below illustrates the T.m_count field in the “TransactionBoundaries” example, above, being a static field. The changed sampleoutput (annotation added) is also illustrated:

public class T extends Transaction {  private boolean   m_commit;  // // m_count field is now static  //  private static int m_count = 0; ... } The corresponding output (annotated) is: # # Initial call toexecute that commits # 1 # # Second call to execute that commits # 2 # #Third call to execute that rolls back - field is not restored since # itis non-transactional # 3

We now discuss some transactional class examples. The example belowshows:

-   -   Behavior of object references in fields    -   Behavior of array references in fields    -   Behavior of accessing references using a local variable

package programming.fluency.transactions; importcom.kabira.platform.annotation.*; importcom.kabira.platform.Transaction; // // Class that can be executed insideor outside of a transaction // class V1 {  Long m_long;  public voidsetField(long value)  {   m_long = value;  } }; // // This class musthave an active transaction context //@Transactional(context=Transactional.Context.REQUIRED) class V2 { private V1 m_v1;  private long m_longs[ ][ ]; @Isolation(level=Isolation.Level.TRANSIENT)  private V1 m_transientV1; private static long m_longstatic;  V2( )  {   super( );   m_v1 = newV1( );   m_longs = new long[10][30];  }  public void update( )  {   //  // This is transactional - modifying   // contents of reference usinga local variable   //   V1 v1 = m_v1;   v1.m_long = 5;   //   // This istransactional - reference replaced   // with a new reference   //   m_v1= new V1( );   //   // This is transactional - assignment through   // atransactional field.   //   m_v1.m_long = 5;   //   // This istransactional - update using method   // in transaction scope   //  m_v1.setField(4);   //   // This is transactional - array updatethrough   // a transactional field   //   m_longs[5][20] = 27;   //   //This is non-transactional - reference replaced   // with a new referencein a non-transactional field   //   m_transientV1 = new V1( );   //   //This is non-transactional - assignment to   // a non-transactionalfield.   //   m_transientV1.m_long = 8;   //   // This isnon-transactional - assignment to   // a static field   //  m_longstatic = 10;  } } public class V extends Transaction {  publicstatic void main (String [ ] args)  {   new V( ).execute( );  } @Override  protected void run( ) throws Rollback  {  new V2( ).update();  } }

We now discuss transaction thread of control. Once a transaction isstarted, all methods called from the run method are in the transaction.An example is shown below:

package programming.fluency.transactions; importcom.kabira.platform.Transaction; public class TC extends Transaction { public static void main (String [ ] args)  {   new TC( ).execute( );  } @Override  public void run( )  {   methodOne( );  }  private voidmethodOne( )  {   //   // This is executing in a transaction   // methodTwo( ); }  private void methodTwo( )  {   //   // This is alsoexecuting in a transaction   //   // ...  } }

The “thread of control” of this transaction can span JVMs and nodes ifthe methods being executed are on distributed objects. Transactions donot span threads in a non-distributed transaction. If a new thread iscreated in a transaction, the new thread is not executing in atransaction when it starts. The creation of a thread is also nottransactional. Specifically if a thread is started in a transaction andthe transaction rolls back, the thread is still running.

The example below shows thread creation.

package programming.fluency.transactions; importcom.kabira.platform.Transaction; class U1 extends Thread {  @Override public void run( )  {   System.out.println(“new thread not in atransaction”);  } } public class U extends Transaction {  public staticvoid main (String [ ] args)  {   new U( ).execute( );  }  @Override public void run( )  {  //  // Create a new daemon thread  //  U1  u1 =new U1( );  u1.setDaemon(true);  //  // The thread is started even ifthe transaction rollsback.  // The thread run method is not in atransaction  //  u1.start( );  } }

We now describe locking and deadlocks. In particular, transaction locksare taken in the following cases on a transactional class:

-   -   Managed Object creation—extent write-locked    -   Managed object deletion—extent write-locked    -   Fields accessed—write lock taken on set, read lock taken on get        Generally, non-managed objects do not take write locks on        creation because there is no extent being maintained.

Read locks are promoted to write locks if object fields are first readand then modified. Transaction locks are held until the currenttransaction commits or aborts.

We now provide an example of object locking.

package programming.fluency.transactions; importcom.kabira.platform.Transaction; importcom.kabira.platform.ManagedObject; /* * L1 Managed Object */ class L1extends ManagedObject {  private L1 ( ) { };  public L1 (String name)  {  this.name = name;  }  public String name;  public boolean lock; } /* *Transaction to create an instance of L1 */ class L2 extends Transaction{  L1  m_a;  @Override  protected void run( )  {   m_a = newL1(“existing”);  } } /* * Transaction to delete an instance of L1 */class L3 extends Transaction {  L1 m_a;  @Override  protected void run()  {   if (Transaction.hasWriteLock(m_a) == false)   {   System.out.println(m_a.name + “: does not have a write lock”);   }  //   // Deleting an object takes a write lock   //   m_a.delete( );  if (Transaction.hasWriteLock(m_a) == true)   {   System.out.println(m_a.name + “: now has a write lock”);   }  } }/* * Main transaction */ public class L extends Transaction {  privateL1 m_a;  public static void main (String [ ] args)  {   L  1 = new L( );  L2  l2 = new L2( );   L3  l3 = new L3( );   l2.execute( );   l.m_a =l2.m_a;   l.execute( );   l3.m_a = l2.m_a;   l3.execute( );  } @Override  protected void run( )  {   L1  a = new L1(“created”);   if(Transaction.hasWriteLock(a) == true)   {    System.out.println(a.name +“: has a write lock”);   }   //   // This object does not have a writelock because it was created   // outside of this transaction. Readingthe name field will   // take a read lock.   //   if(Transaction.hasWriteLock(m_a) == false)   {   System.out.println(m_a.name + “: does not have a write lock”);   }  if (Transaction.hasReadLock(m_a) == true)   {   System.out.println(m_a.name + “: now has a read lock”);   }   //   //Take a write lock by setting the lock attribute. This   // promotes theread lock taken above when name was read.   //   m_a.lock = true;   if(Transaction.hasWriteLock(m_a) == true)   {   System.out.println(m_a.name + “: now has a write lock”);   }  } }

When the above example executes, it generates the following output:

created: has a write lock existing: does not have a write lock existing:now has a read lock existing: now has a write lock existing: does nothave a write lock existing: now has a write lock

Deadlocks are handled transparently such that deadlocks do not have tobe explicitly handled by the application. When a deadlock occurs, theTransaction class detects the deadlock, rolls back the currenttransaction and restarts a new transaction by calling the run methodagain.

We now discuss explicit locking. That is, it is possible to explicitlytransaction lock objects. Explicit transaction locking is useful toavoid lock promotions. A lock promotion happens when an object has aread lock and then the object is modified. This is usually caused byfirst reading a field value and then modifying the object.

These mechanisms are available to explicitly lock objects:

-   -   Transaction.readLockObject—explicitly read lock an object    -   Transaction.writeLockObject—explicitly write lock an object    -   Base.selectUsing . . . —explicitly lock an object when selecting        it.        The Base.selectUsing . . . method is discussed in detail later.

The example below show how to avoid a lock promotion.

package programming.fluency.transactions; importcom.kabira.platform.annotation.*; importcom.kabira.platform.Transaction; @Transactional class B1 {  Stringinput;  String output; } public class B extends Transaction {  enumAction  {   PROMOTE,   WRITELOCK  }  private B1  m_b1;  private Actionm_action; public static void main (String [ ] args) {  B  b = new B( ); b.m_b1 = new B1( );  b.m_action = Action.PROMOTE;  b.execute( ); b.m_action = Action.WRITELOCK;  b.execute( ); } void reportLock(Stringmsg) {  System.out.println(msg + “ B1: read lock = ”   +Transaction.hasReadLock(m_b1) +   “, write lock = ”   +Transaction.hasWriteLock(m_b1)); } @Override protected void run( )throws Rollback {  if (m_action == Action.PROMOTE)  {  reportLock(“promote: enter”);   //   // Accessing input takes a readlock   //   String i = m_b1.input;   reportLock(“promote: read”);   //  // Read lock is promoted to write lock. Note this   // also happenswhen the following is executed:   //   // m_b1.output = m_b1.input;   //  m_b1.output = i;   reportLock(“promote: write”);  }  else  {   assert( m_action == Action.WRITELOCK );   reportLock(“writelock: enter”);   //  // Explicitly take write lock to avoid promotion   //  Transaction.writeLockObject(m_b1);   //   // Accessing input willalready have write lock   //   String i = m_b1.input;  reportLock(“writelock: read”);   //   // No promotion of locks happen  //   m_b1.output = i;   reportLock(“writelock: write”);   }  } }

The output of the preceding example (annotated) is as follows:

[primary] promote: enter B1: read lock = false, write lock = false # #Read lock is taken when field on B1 is read # [primary] promote: readB1: read lock = true, write lock = false # # Write lock is taken whenfield on B1 is set # [primary] promote: write B1: read lock = true,write lock = true [primary] writelock: enter B1: read lock = false,write lock = false # # Explicitly write lock B1 causes both the read andwrite lock # to be taken on B1 # [primary] writelock: read B1: read lock= true, write lock = true [primary] writelock: write B1: read lock =true, write lock = true

We now discuss integration of transactions with JAVA monitors. JAVAmonitors are integrated with transactions to ensure that the JAVAmonitor transactions do not deadlock with transaction locks. FIG. 8shows an undetected deadlock between a JAVA monitor and a transactionlock. These undetected deadlocks may be avoided using the mechanismsdescribed in this section.

Monitors can still deadlock with themselves inside or outside of atransaction. Standard monitor deadlock avoidance techniques may be used.To avoid transaction and monitor deadlocks, the following steps may beperformed when acquiring transaction locks on any object:

1. Object monitor not held on the object, perform normal transactionlocking.

2. Object monitor held on the object, attempt to get transaction lock.

3. If transaction lock uncontested (can acquire without waiting), taketransaction lock.

4. If transaction lock contested (a wait would be required to acquirethe lock), rollback the current transaction

These rules are illustrated by the sequence diagram in FIG. 9.

An implication of this monitor and transaction deadlock avoidanceapproach is that there may be false transaction rollbacks when monitorsare used in transactions with contested transaction locks. In general,monitors may not be needed in a transactional system because transactionisolation provides the same data integrity guarantees with much betterconcurrency and ease of use.

When a failure occurs, compensation may be done to ensure that any workthat was completed before the failure is restored to its initial state.Transactional resources are automatically restored to their initialstate by rolling back any changes when a transaction aborts. Explicitcontrol over the resolution of a transaction is supported with theTransaction.Rollback exception. This mechanism can be used to recoverfrom failures when a transaction is running.

When non-transactional resources (e.g. a file or network connection) aremodified during a transaction and an error is detected, or thetransaction rolls back, application code may be provided to restore thenon-transactional resource to their initial state.

Notification of transaction resolution may be supported using thekabira.platform.swbuiltin.transactionNotifier class. This class providesonRollback and onCommit methods that can be implemented as required tomanage non-transactional resources. Multiple transaction notifiers canbe created during the same transaction. The appropriate method is calledfor each notifier instance created when the transaction completes. Theorder in which multiple notifiers are called is typically undefined sothere should be no order assumptions in the notifiers. A notifier thatis created in a transaction can be deleted before the transactioncompletes. In this case, the notifier is not called when the transactioncompletes.

The following provides an example use of transaction notifiers:

package programming.fluency.transactions; importcom.kabira.platform.swbuiltin.*; import com.kabira.platform.Transaction;class Compensation extends TransactionNotifier {  String name; @Override  public void onRollback( )  {   //   // Perform applicationspecific rollback processing   //   System.out.println(name + “:onRollback called”);   //   // Do not need to call delete. The notifierinstance   // deletes itself.   //  } @Override public void onCommit( ){  //  // Perform application specific commit processing  // System.out.println(name + “: onCommit called”);  //  // Do not need tocall delete. The notifier instance  // deletes itself.  //  } } publicclass N extends Transaction {  Transaction.Result result;  public staticvoid main (String [ ] args)  {   N  n = new N( );   n.result =Result.COMMIT;   n.execute( );   n.result = Result.ROLLBACK;  n.execute( );  } @Override protected void run( ) throwsTransaction.Rollback {  op1( );  op2( );  op3( );  if (result ==Result.ROLLBACK)  {   throw new Transaction.Rollback( );  } }  void op1()  {   Compensation compensation = new Compensation( );  compensation.name = “op1”;  }  void op2( )  {   Compensationcompensation = new Compensation( );   compensation.name = “op2”;  } void op3( )  {   //   // Create and delete a notifier in the sametransaction.   // This notifier is not called when the transactioncompletes.   //   Compensation compensation = new Compensation( );  compensation.name = “op3”;   compensation.delete( );  } }

The immediately preceding example may, when executed, result in thefollowing output:

# # commit compensation executed for op1 # op1: onCommit called # #commit compensation executed for op2 # op2: onCommit called #Compensation # rollback compensation executed for op1 # op1: onRollbackcalled # # rollback compensation executed for op2 # op2: onRollbackcalled

We now discuss transaction notifier restrictions. The onCommit andonRollback methods in a transaction notifier cannot take any newtransaction locks. All transaction locks should be taken before theonCommit or onRollback methods are called. This restriction alsoprecludes any objects with extents from being created or deleted inthese methods because an object create takes an implicit write lock.

We now discuss unhandled exception handling. Unhandled exceptions in atransaction may cause the current transaction to rollback and thecurrent thread to exit. If the current thread is the thread in whichmain was executed, the JVM will exit. Any installed transactionnotifiers are called before the thread exits (including the mainthread). The example below illustrates an unhandled exception in themain thread.

package programming.fluency.transactions; importcom.kabira.platform.Transaction; import com.kabira.platform.swbuiltin.*;class UnhandledException extends JAVA.lang.Error { } class F extendsTransactionNotifier {  @Override  public void onRollback( )  {   //   //Perform application specific rollback processing   //  System.out.println(“onRollback called”);  } } public class E extendsTransaction {  public static void main (String [ ] args)  {   new E().execute( );  }  @Override  protected void run( )  {   //   // Create atransaction notifier   //   new F( );   //   // Throw an unhandledexception - transaction rolled back   //   throw new UnhandledException();  } }

When the preceding example runs, it outputs (annotation added):

# # Application onRollback method called before JVM exits # onRollbackcalled JAVA main class programming.fluency.transactions.E.main exitedwith an exception. JAVA exception occurred:programming.fluency.transactions.- UnhandledException  atprogramming.fluency.transactions.E.run(E.JAVA:55)  atcom.kabira.platform.Transaction.execute(Transaction.JAVA:117)  atprogramming.fluency.transactions.E.main(E.JAVA:41)

We now discuss a transaction required exception. In particular,attempting to use a class that has a@Transactional(context=Transactional.Context.REQUIRED) annotationoutside of a transaction may cause the following exception to be thrown:JAVA.lang.IllegalAccessError. This exception is illustrated in thefollowing example:

package programming.fluency.transactions; importcom.kabira.platform.annotation.*; importcom.kabira.platform.ManagedObject;@Transactional(context=Transactional.Context.REQUIRED) class X1 extendsManagedObject { }; public class X {  public static void main (String [ ]args)  {   //   // Attempting to use a transactional required class   //outside of a transaction   //   new X1( );  } }

If the preceding example is executed, it results in the following output(annotated):

# # JAVA.lang.IllegalAccessError thrown because X1 requires atransaction # JAVA main class programming.fluency.transactions.X.mainexited with an exception. JAVA exception occurred:JAVA.lang.IllegalAccessError: no active transaction  atcom.kabira.platform.ManagedObject._createSMObject(Native  Method)  atcom.kabira.platform.ManagedObject.<init>  (ManagedObject.JAVA:118)  atprogramming.fluency.transactions.X1.<init>(X.JAVA:7)  atprogramming.fluency.transactions.X.main(X.JAVA:19)

We now discuss JAVA Native Interface (JNI) transactional programming. Inparticular, the JAVA Native Interface becomes transactional. This meansthat all memory allocated, read, modified, or deleted using JNI APIs istransactional—it is logged and locked. In addition, transactionalisolation is provided for field data.

All JNI code that accesses transactional resources should check fordeadlock exceptions after each call and return to the caller. This isdone the same way as all other exception handling in JNI.

Following is an example of Transactional JNI Programming.

static void JNICALL JAVA_com_kabira_platform_someClass_someNative(JNIEnv*env, jclass) {  doSomeWork(env);  //  // Check for an exception - thiscould be a deadlock  //  if (env->ExceptionCheck( ))  {   // propagateexception to caller   return;  }  doMoreWork(env);  if(env->ExceptionCheck( ))  ... }

In some examples, native resources such as file descriptors, sockets, orheap memory are not transactional.

Transaction modifiers may be used to support transaction safe managementof non-transactional resources. The onCommit or onRollback methods canbe implemented as native methods to perform this management.

We now summarize some high-level guidelines for using transactionalclasses. These are not hard and fast rules, but guidelines that shouldbe evaluated in a specific application context. First, the use of JAVAmonitors in transactions should be avoided or at least minimized.Deadlocks should also be avoided. When locking multiple objects, theobjects should be locked in the same order. Concurrently locking objectsin different orders can result in deadlocks. The deadlocks will bedetected and handled transparently, but it is less expensive to avoidthem. Promotion deadlocks should be avoided. When an object is going tobe modified (written) within a transaction, the write lock should betaken first, instead of the read lock. This avoids the possibility ofpromotion deadlock between multiple transactions. Again, these deadlocksare detected and handled transparently, but it is less expensive toavoid them. Resource contention should be avoided. Adding single pointsof contention to an application should be avoided. If the applicationexecutes multiple threads concurrently, it should be ensured that eachthread uses separate resources. It should be attempted to minimize theduration of transaction locks to avoid lock contention. For example,blocking with transaction locks held waiting for data from an externalsource, or sleeping with transaction locks held is generally bad.

We now describe managed objects. In one example environment, there arethree types of managed objects:

Parent Class Behavior com.kabira.platform.ManagedObject Shared MemoryPersistence, Distribution com.kabira.platform.ha.MirroredObject SharedMemory Persistence, High Availability Mirroringcom.kabira.platform.ha.ReplicatedObject Shared Memory Persistence, HighAvailability Mirroring, Replication

Managed Objects have an @Transactional(Context=REQUIRED) transactionannotation—they can only be manipulated in a transaction. Below is anexample of a Managed Object that is persisted in shared memory, such asis illustrated in FIG. 10.

package programming.fluency.managedobjects; importcom.kabira.platform.ManagedObject; @managed public class A {    //    //Name is stored in shared memory    //    String name; }

As shown in FIG. 10, the shared memory 1002 includes the class A,including the string “name.” Distribution may be added to the aboveobject using annotation.

An example of a Mirrored Managed Object that is persisted in sharedmemory is now provided.

package programming.fluency.managedobjects; importcom.kabira.platform.ha.*; public class B extends MirroredObject {   public B( )    {       //       // Create mirrored object in fluencypartition group using       // partition number 0. A default identifieris used.       //       super (“fluency”, 0, null);    }    //    //Name is transactionally mirrored on backups and persisted    // inshared memory    //    String name; }

An example is now provided of a Replicated Managed Object that isreplicated to all nodes and persisted in shared memory.

package programming.fluency.managedobjects; importcom.kabira.platform.ha.*; public class C extends ReplicatedObject {   public C( )    {       //       // Create replicated object influency partition group using       // partition number 0. A defaultidentifier is used.       //       super (“fluency”, 0, null);    }   //    // Name is replicated to all configured nodes, mirrored to   // a backup node and persisted in shared memory    //    String name;}

As shown in FIG. 11, the string “name” is maintained on a primarypartition 1102, a backup partition 1104 and a replica 1106. Thus, theenvironment provides application-transparent mirrored and replica JAVAobjects (synchronous and asynchronous), and HA timers, includingtransparent HA JAVA object/message routing 1108. In addition, datapartitioning and partition migration capabilities are provided.

Prior to discussing how objects may be managed, we discuss some detailsof a development environment to develop fully transactional applicationsusing standard JAVA language constructs. Referring to FIG. 12, a servercluster 1202 may be pre-configured and accessed using a standard JAVAdevelopment environment 1204 such as NetBeans, Eclipse and J-Builder.Objects may be edited, built, debugged and profiled using JAVA tools. A“Shared Memory” monitor tool 1206 may be used to load JAVA typedescriptors into the transaction platform runtime environment. A clusteradministration GUI 1208 may be used to administer the domains; the nodesbeing automatically registered to the domain manager 1210.

FIG. 13 illustrates, in greater detail, a service (such as the service104 of the FIG. 1 environment), in accordance with an example. As shownin FIG. 13, the service 1300 may include a VM layer 1302 and atransaction processing layer 1304. The transaction processing layer 1304may include various services, including infrastructure services 1306.Thus, for example, the service in FIG. 13 may appear as a standardJVM—shipped, integrated and certified as a JAVA Virtual Machine, such ascertified by Sun Microsystems. JAVA code transparently executes withtransaction processing semantics; all transaction processing facilitiesare available in JAVA. A class loader may make the standard JAVA syntaxwork transparently for transaction processing objects and dynamicallyfetches classes as needed during runtime.

In some examples, minimal opcode routines may be required to berewritten to bind JVM to the transaction processing so that the JAVAwill execute transparently with transaction processing semantics (e.g.,transactions, POJO locks, etc.). JIT compatibility may be maintained andstandard JNI tables used for linkage.

An agent 1308 and JAVA client 1310 may interoperate to transparentlyintegrate development environments to the transaction processing (e.g.,with respect to class negotiation, execution, etc.) In addition, in someexamples, users are able to use JAVA SE development tools (such asdebuggers) without modification.

The transparent integration is a result, in part, of transactionbindings and enhancement of the JVM interpreter. An example of thisconcept is shown in FIG. 14. In FIG. 14, a JAVA class 1402 is shown asbeing provided to an enhanced JVM interpreter 1404. JAVA NativeInterface (JNI) methods 1406 are registered to the JNI so that a JNIruntime function binding 1408 binds the JAVA execution control totransaction processing platform runtime services in FIG. 14. Thus, forexample, JAVA transaction context lifecycle may be managed via begin,commit and abort bindings.

A slightly modified version of the JVM interpreter may be active duringtransaction execution for subsequent transparent locking, deadlockdetection, etc. FIG. 15 illustrates an example of such a slightlymodified transaction processing enabled JVM 1502. In particular, whenthe JVM 1502 executes in a transactional context, certain transactionalJVM functions (such as the putfield(−) function 1504 in FIG. 15) arereplaced by a variant (i.e., in FIG. 15, the putfield( ) function 1506),and the JAVA code executes transparently, with transactional processingsemantics. If not in a transactional mode, the modified JVM may runwithout any transaction processing overhead, with a separate byte codeinterpreter being utilized while in the transactional mode. The opcoderewrites may be specified in assembler language to optimize performance.The transactional processing environment maintains a table 1508 thatmaps the VM function to runtime services of the transaction processingservice 1512. Using the FIG. 15 example, the class loader has previouslyloaded the JAVA “Customer” type descriptor in the transaction processingservice, so that the “Customer” type as specified using JAVA maps to the“Customer” type in the transaction processing service 1512.

FIG. 16 illustrates functionality of an example of the transactionprocessing platform class loader. Basically, as just discussed withreference to FIG. 15, the class loader operates to extend the JVMversion to populate JAVA class information into the transactionprocessing runtime system. Thus, for example, the JAVA code whenexecuted can result in transparently creating persistent transactionprocessing objects via the standard JAVA “new” operator. As anotherexample, the JAVA code can result in execution of operations ontransaction processing objects via a standard JAVA method invocation.Transaction processing objects can be read and modified via standardJAVA member access (e.g., not special getters & setters). Virtualtransaction processing methods may be transparently overridden, withevents being transparently dispatched from the transaction processingservice to the JVM. A JAVA class may be derived from a transactionprocessing interface.

Referring now to FIG. 16, when the JAVA client 1602 is handling anapplication that requires a class, the client 1602 first tries to locatethe class in the server class path of the server file system 1604. FIG.16 shows classes being loaded from the client and mapping to typedescriptors in the transaction processing service.

The JAVA client permits for remote development on any JAVA-equippedplatform, interfacing with the transaction processing servers to deploy,execute and debug transaction processing enabled JAVA applications.Thus, for example, the application may be executed from the command lineor Commercial off-the-shelf integrated development environment. Uponexecution, the client opens a connection the agent running on the targetnode and sends command, options and application data (e.g., JAVA classand JAR files) to the transaction processing server. The agent monitorsexecution of the application, including displaying console output of theapplication for that client. In addition, the agent can respond torequest for additional JAVA classes needed by the node during runtime.In addition, a JAVA debugger can be attached at any time, and debuggingand profiling can be carried out remotely via a JAVA IDE. Also, servicenames registered to MDNS (multicast domain name service) can bedisplayed and reference via the transaction processing node service.

Examples of client usage include:

JAVA -jar ktp.jar [options] <target> [application arguments] JAVA -jarktp.jar [options] help JAVA -jar ktp.jar [options] display services

The following table illustrates examples of command options for the JAVAclient:

Option Description adminport The administration port of the Fluency nodethat should be used to run the application. autoconfigure This option,when given a value of true, requests that the Fluency node load andactivate node configuration files before the application starts, anddeactivate/remove those configurations when the application terminates(default: false). Debug A boolean flag indicating whether diagnosticoutput is required (default: false) detailed A boolean flag indicatingwhether the ‘display services’ command output should contain detailedresults (default: false) displayversion A boolean flag indicatingwhether the Fluency version information should be displayed (default:true). domainname The name of the domain that the application is to runon. When this option is used, the deployment tool must connect to aKabira Domain Manager node which is managing the given domain. Theapplication will execute on all nodes in the domain. domaingroup Thename of the domain group that the application is to run on. When thisoption is used, the deployment tool must connect to a Kabira DomainManager node which is managing the given domain group. The applicationwill execute on all nodes in the domain group. domainnode The name ofthe domain node that the application is to run on. When this option isused, the deployment tool must connect to a Kabira Domain Manager nodewhich is managing the given domain node. The application will execute onthe specified node. Hostname The host name hosting the Fluency node thatshould be used to run the application (default: localhost). password Thepassword to use when authenticating username during the connection tothe Fluency node. remotedebug If true, require the JVM hosting theapplication to enable remote debugging (default: false for PRODUCTIONnodes, true for DEVELOPMENT nodes). remotedebugport The debugger agentport, to be used by the JVM to listen for remote debugger clients(default: randomly chosen by the JVM). reset This option, when given avalue of true, requests that all Java objects and type definitions onthe node be deleted before the application begins execution (default:true). Servicename The service name of the Fluency node that is to beused to run the application. This option may be used instead ofadminport and hostname. This option only works if MDNS service discoveryis configured on the local machine. suspend If true, require the JVM tosuspend execution before main( ) is called during remote debugging. Thisoption only applies if remotedebug = true is specified (default: false).timeout The number of seconds to wait while resolving servicename withMDNS (default: 10). username The user name to use when connecting to aFluency node. The specified value must identify a principal withadministrative privileges on the node. x509credential The X509certificate keystore file to use for authentication. If given, thepassword parameter is required, and should be the keystore passwordx509credentialalias The alias of the user's X509 certificate in thekeystore specified by the x509credential option (default: mykey).

Particular examples of use of such options include:

JAVA -jar ktp.jar display services JAVA -jar ktp.jar servicename=primarypojotransactiondemo.jar JAVA -jar ktp.jar servicename=primaryremotedebug=true pojotransactiondemo.jar

FIG. 17 illustrates how an agent 1702 may manage server-sideresponsibilities of a remote development interface. More particularly,when a request is received from a JAVA client 1704, the agent 1702authenticates the request using SSL-based authentication via thetransaction processing service 1706 administrative framework. The agent1702 requests and receives JAVA application classes from the client 1704as needed during runtime, requesting and receiving additional classesfrom the client 1704 as needed during runtime. The agent 1702 places theclasses in a node-specific location (JAVA class cache 1708) to beavailable for class loading and execution. The agent generates adeployment specification 1710 defining a JVM with the user's classes,virtual machine options and parameters.

An application's lifecycle includes, for example, a client 1704commanding load, into the engine, of the deployment specification 1710generated by the agent 1702. The client 1704 polls for stdout/stderroutput from the engine and causes the output to be displayed on aconsole. When the engine exits, the engine exit code is returned as thecommand return code. If the client exits before the JAVA client 1704request completes, the engine is stopped, the deployment specification1710 is unloaded, and the state of the application is removed by theagent 1702.

We now describe an example of the life cycle of a managed object. Allcreates, reads, updates, and deletes of managed objects should be donein a transaction. Creating an object in a transaction that rolls backremoves the object from shared memory. Deleting an object in atransaction that rolls back leaves the object in shared memory.

As mentioned above in the introduction to basic concepts, managedobjects are not garbage collected by the JVM. Only the proxy JAVA objectthat references the managed object is garbage collected—the sharedmemory state of the object itself remains. Managed objects should beexplicitly deleted by calling the delete method, an example of whichfollows:

package programming.fluency.managedobjects; importcom.kabira.platform.ManagedObject; importcom.kabira.platform.Transaction; class E extends ManagedObject { };public class D extends Transaction {    public static void main (String[ ] args)    {       new D( ).execute( );    }    @Override    protectedvoid run( )    {       E   e = new E( );       //       // Deleteinstance in shared memory       //       e.delete( );    } }

After the delete method is called on a managed object, using the JAVAreference to invoke methods or access a field will cause theJAVA.lang.NullPointerException exception to be thrown. TheManagedObject.isEmpty( ) method can be used to test whether the sharedmemory backing a JAVA reference has been deleted.

Managed objects may automatically maintain an extent. The extent makesit possible to find all instances of a managed object at any time.Applications should not rely on any ordering of objects in an extent.The following is an example of managed object extents:

package programming.fluency.managedobjects; importcom.kabira.platform.ManagedObject; importcom.kabira.platform.Transaction; importcom.kabira.platform.ManagedObjectSet; class I extends ManagedObject {   I (int number)    {       super( );       this.number = number;    }   int number; } public class H extends Transaction {    public staticvoid main (String [ ] args)    {       new H( ).execute( );    }   @Override    protected void run( )    {       int j;       //      // Create objects in shared memory       //       for (j = 0; j <10; j++)       {          new I(j);       }       //       // Iteratethe extent deleting all of the created objects       //      ManagedObjectSet<I> iExtent =       ManagedObject.extent(I.class);      for (I i : iExtent)       {          System.out.println(i.number);         i.delete( );       }    } }

We now describe locking and isolation. Extents support a transactionisolation of READ COMMITTED. This means that a write lock is not takenon an extent when an object is created or destroyed. This does implythat two extent iterations of the same extent in a transaction mayreturn different results if other transactions have committed betweenthe two iterations.

A specific extent isolation that may be supported is:

-   -   creates are always visible in the transaction in which they        occur;    -   deletes are visible in the transaction in which they occur on        objects that were created in the same transaction; and    -   deletes are visible after the transaction commits on objects        that were created in a separate transaction

The example immediately following demonstrates there rules:

package programming.fluency.managedobjects; importcom.kabira.platform.*; class J1 extends ManagedObject { } public class Jextends Transaction {    enum Action    {       CREATE,       BOTH,      DELETE    }    private Action m_action;    private Stringm_message;    public static void main (String [ ] args)    {       J   j= new J( );       j.m_action = Action.BOTH;       j.m_message = “SameTransaction”;       j.execute( );       j.m_action = Action.CREATE;      j.m_message = “Separate Transactions”;       j.execute( );      j.m_action = Action.DELETE;       j.m_message = “SeparateTransactions”;       j.execute( );    }    @Override    protected voidrun( ) throws Rollback    {       int   i;       if ((m_action ==Action.BOTH) || (m_action ==       Action.CREATE))       {          for(i = 0; i < 10; i++)          {             new J1( );          }      }       ManagedObjectSet<J1> extent =      ManagedObject.extent(J1.class);       if ((m_action ==Action.BOTH) || (m_action ==       Action.CREATE))       {         System.out.println(m_message);         System.out.println(extent.size( ) +          “ objects inextent after create”);       }       if (m_action == Action.BOTH ||m_action ==       Action.DELETE)       {          for (J1 j1 : extent)         {             j1.delete( );          }         System.out.println(extent.size( ) + “          objects inextent after delete”);       }    } }

When the preceding example is executed, the following output results(annotation added):

# # Both creates and deletes are reflected because both are done # inthe same transaction # Same Transaction 10 objects in extent aftercreate 0 objects in extent after delete # # Deletes are not reflecteduntil the transaction commits because # creates occurred in a separatetransaction # Separate Transactions 10 objects in extent after create 10objects in extent after delete

Objects accessed through extent iteration do not have a transaction lockwhen they are returned. A transaction lock is not taken on the objectuntil a field is accessed or the object is explicitly locked. Asdiscussed above, there is no lock taken on an extent when objects arecreated or deleted. The combination of no extent locking, and a lock notbeing taken on objects returned from extent iteration, may cause deletedobject references being returned from an extent. The following is anexample of extent object locking:

package programming.fluency.managedobjects; importcom.kabira.platform.Transaction; importcom.kabira.platform.ManagedObject; importcom.kabira.platform.ManagedObjectSet; import JAVA.util.logging.Level;import JAVA.util.logging.Logger; class K1 extends ManagedObject { }; //// This thread creates and deletes Managed Objects in shared memory. //Sleep to introduce some variability // class K2 extends Thread {   private static final int NUMBERITERATIONS = 10;    @Override   public void run( )    {       int  i;       for (i = 0; i <NUMBERITERATIONS; i++)       {          try          {             newK3(K3.Action.CREATE).execute( );             Thread.sleep(1000);            new K3(K3.Action.DELETE).execute( );          }         catch (InterruptedException ex)          {            Logger.getLogger(K2.class.getName( )).         log(Level.SEVERE, null, ex);          }       }    } } // //Transaction to create and delete Managed Objects // class K3 extendsTransaction {    private static final int COUNT = 100;    enum Action   {       CREATE,       DELETE    }    K3 (Action action)    {      m_action = action;    }    private Action m_action;    @Override   protected void run( ) throws Rollback    {       //       // Createmanaged Managed Objects       //       if (m_action == Action.CREATE)      {          int i;          for (i = 0; i < COUNT; i++)          {            new K1( );          }       }       else       {         assert ( m_action == Action.DELETE );         ManagedObjectSet<K1> extent =         ManagedObject.extent(K1.class);          //          // Iterateextent - test for deleted objects, delete          // ones that are notalready deleted by another thread          //          for (K1 k :extent)          {             if (k.isEmpty( ) == false)             {               k.delete( );             }          }       }    } }public class K { private static final int NUMBERTHREADS = 15;    publicstatic void main (String [ ] args) throws    InterruptedException    {      int   i;       K2   threads[ ] = new K2[NUMBERTHREADS];       for(i = 0; i < NUMBERTHREADS; i++)       {          threads[i] = new K2( );         threads[i].start( );       }       //       // Wait for all ofthe threads to exit       //       for (i = 0; i < NUMBERTHREADS; i++)      {          threads[i].join( );       }    } }

We now discuss array copy-in/copy-out. When a field in a managed objectis accessed, transactional locking and logging occur. This is true forprimitive types, arrays, and objects.

Arrays can also be copied into a local array variable to avoidtransactional locking or logging. This copy occurs implicitly if anarray is passed into a method for execution. Shared memory backing anarray is only modified when elements in the array are modified using theobject reference containing the array. These cases are shown in theexample below.

Array copies are a useful performance optimization when a large numberof elements in an array are being modified in a single transaction.

The following provides an example of array copy-in/copy-out.

package programming.fluency.managedobjects; importcom.kabira.platform.ManagedObject; importcom.kabira.platform.Transaction; class F2 extends ManagedObject {    intvalue; } class F1 extends ManagedObject {    F1( )    {      sharedMemoryArray = new int[10];       int i;       for (i = 0; i< 10; i++)       {          sharedMemoryArray[i] = i;       }      objectArray = new F2[2];       for (i = 0; i < 2; i++)       {         F2 f2 = new F2( );          f2.value = i;         objectArray[i] = f2;       }    }    int [ ] sharedMemoryArray;   F2 [ ] objectArray; } public class F extends Transaction {    publicstatic void main (String [ ] args)    {       new F( ).execute( );    }   @Override    protected void run( )    {       F1 f = new F1( );      //       // Read lock f and make of copy of sharedMemoryArray      in localArray       //       int localArray[ ] =f.sharedMemoryArray;       //       // This does not modify sharedmemory       //       localArray[2] = 6;      System.out.println(“localArray: ” + localArray[2]          + “sharedMemoryArray: ” +          f.sharedMemoryArray[2]);       //      // This modifies shared memory and takes a write lock on f      //       f.sharedMemoryArray[2] = 7;      System.out.println(“localArray: ” + localArray[2]          + “sharedMemoryArray: ” +          f.sharedMemoryArray[2]);       //      // This does not modify shared memory       //      modifyIntArray(localArray);       System.out.println(“localArray:” + localArray[0]          + “ sharedMemoryArray: ” +         f.sharedMemoryArray[0]);       //       // This does not modifyshared memory.       // It takes a read lock on f.       //      modifyIntArray(f.sharedMemoryArray);      System.out.println(“localArray: ” + localArray[0]          + “sharedMemoryArray: ” +          f.sharedMemoryArray[0]);       //      // This copies the value of localArray into shared memory       //and takes a write lock on f.       //       f.sharedMemoryArray =localArray;       System.out.println(“localArray: ” + localArray[0]         + “ sharedMemoryArray: ” +          f.sharedMemoryArray[0]);      //       // This copies only the object references in objectArrayto a       // local array - i.e. it does not perform a deep copy.      //       F2 localF2Array[ ] = f.objectArray;       //       //This updates shared memory through the object reference       // copiedinto the local array       //       localF2Array[0].value = 8;      System.out.println(“f2.value: ” + f.objectArray[0].value);       }   void modifyIntArray(int [ ] arg)    {       arg[0] = 5;    } }

When the preceding example is run, it results in the following output:

# # Modify local array with a value of 6 # localArray: 6sharedMemoryArray: 2 # # Modify shared memory with a value of 7 #localArray: 6 sharedMemoryArray: 7 # # Modify local array with a valueof 5 # localArray: 5 sharedMemoryArray: 0 # # Modify shared memory arraypassed to a method with a value of 5 # localArray: 5 sharedMemoryArray:0 # # Copy local array into shared memory array # localArray: 5sharedMemoryArray: 5 # # Modify shared memory using an object referencein a local array # f2.value: 8

When the preceding example is executed, it outputs (annotation added):

# # Original value of 5th element of intArray # intArray[5] == 5 # # 5thelement still contains a value of 5 even after being set to 0 byReflection API # intArray[5] == 5

We now discuss the use of distributed computing features in atransactional application. In general, in accordance with an example,any managed object can be a distributed object using configuration data.Supported configuration values are described below.

Distribution configuration may be done using configuration files, anexample syntax of which is discussed later. Distribution configurationdefines a nested configuration block named Distribution. It also definesthe following configuration interfaces:

-   -   DistributedObject—distributed object configuration    -   DirectedCreateObject—directed create distributed object        configuration    -   CacheGroupObject—cache group distributed object configuration

The example below shows how the distribution configuration block andinterfaces may be used.

package com.kabira.platform.annotation; import java.lang.annotation.*;/** Mark a class as Distributed, and provide initial configuration  *values for distribution type config.  */ @Documented @Inherited@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) public@interface Distributed {    /** Defines the legal cache policies fordistributed objects.    */    public static enum CacheType    {      /** The cached copy is never considered valid. Every       *access to this object will cause the cached data       * to berefreshed.       */       NEVER,       /** The cached copy is alwaysconsidered valid. It is       * never refreshed.       */       ALWAYS,      /** The first time an object is accessed, the cache       * isconsidered stale. After that the cached copy is       * alwaysconsidered valid. It is never refreshed again.       */       ONCE,      /** The cached copy is considered valid for a configured       *amount of time (the cache timeout). If the object is       * accessedafter the cache timeout has elapsed since the       * last time it wasread onto the node, it will be refreshed.       */       TIMED    };   /** The cache policy controls when cached data is considered    *stale and should be read from the node on which the object    * wascreated. Default value is CacheType.ALWAYS.    */    CacheTypecacheType( ) default CacheType.ALWAYS;    /** Refresh time in seconds;only valid if cacheType is    CacheType.TIMED.    */    longcacheTimeSeconds( ) default 0L;    /** A value of true enablesasynchronous writes. Default false.    */    boolean asyncWrite( )default false;    /** A value of true enables asynchronous destroys.Default false.    */    boolean asyncDestroy( ) default false;    /**Cache groups provide support for pushing cache data    * to a configuredcache group by mapping the cache group to a    * set of network nodes.By default, the cache group is disabled.    */    CacheGroup cacheGroup() default @CacheGroup(       enabled = false,       groupName = “”,      asyncCreate = false);    /** Directed create causes all objectcreates to be directed    * to the node indicated by nodeName. Bydefault,    * directed create is disabled.    */    DirectedCreatedirectedCreate( ) default @DirectedCreate(       enabled = false,      nodeName = “”);

The configuration attributes supported by the distribution configurationinterfaces, in an example, are summarized below.

Name Type Description typeName Unbounded String Class name, includingthe package prefix of the distributed object cacheType Enumeration -Control cache policy of CacheNever, distributed object. CacheAlways,CacheOnce, or CacheTimed cacheTimeSeconds Unsigned long Refresh time inseconds. Only valid if cache-Type is Cache Timed. asyncWrite BooleanTrue or false. A value of true enables asynchronous writes. asyncDestroyBoolean True or false. A value of true enables asynchronous destroys.

The cache group configuration may have the following additionalconfiguration values in addition to the DistributedObject configurationvalues.

Name Type Description groupName Unbounded String Cache group name inwhich this object participates. asyncCreate Boolean True or false. Avalue of true enables asynchronous creates.

The directed create configuration has the following additionalconfiguration values in addition to the DistributedObject configurationvalues.

Name Type Description modeName Unbounded String A string valuecontaining the node name used for all object creates.

We now describe an example of a distributed object life cycle.Distributed objects have the same life cycle as any managed object.However, if an object maintains a reference to a distributed object,that object can be deleted on a remote node and the local object now hasa stale reference. This stale reference is generally not detected untila field or a method on the reference is invoked. In this case thefollowing exception is thrown.

// // Invalid distributed reference detected //JAVA.lang.NullPointerException

The example below illustrates how to configure and create a DirectedCreate type. There is no difference between creating a Directed Createtype and a non-directed create type—both use new to create a newinstance.

// // NAME // $RCSfile: DirectedCreate.java,v $ // // COPYRIGHT //Confidential Property of Kabira Technologies, Inc. // Copyright 2008,2009 by Kabira Technologies, Inc. // All rights reserved. // // HISTORY// $Revision: 1.9 $ // package com.kabira.snippets.distributedcomputing;import com.kabira.platform.*; import com.kabira.platform.annotation.*;import com.kabira.platform.swbuiltin.EngineServices; /** * DirectedCreate distributed objects. * <p> * <h2> Target Nodes</h2> * <ul> * <li><b>domainname</b> = Fluency Development * </ul> */ public classDirectedCreate extends Transaction {   private Action m_action;  private boolean m_done;   DirectedCreate( )   {     m_done = false;  }   /**   * Control program execution   */   enum Action   {     /**    * Create objects     */     CREATE,     /**     * Wait on replicanode for all creates to complete     */     WAIT   } /** * Directedcreate object */ @Distributed(   directedCreate=  @com.kabira.platform.annotation.DirectedCreate(nodeName=   “replica”))public static class DirectedCreateObject {   /**   * Create a new object  */   public DirectedCreateObject( )   {     super( );     createdOn =EngineServices.getNodeName( );   }   /**   * Node on which object wascreated   */   public String createdOn; } /** * Main entry point * *@param args Not used */ public static void main(String [ ] args) throwsInterruptedException {   DirectedCreate directedCreate = newDirectedCreate( );   directedCreate.m_action = Action.CREATE;  directedCreate.execute( );   while (directedCreate.m_done == false)  {     directedCreate.m_action = Action.WAIT;    directedCreate.execute( );     Thread.sleep(1000);   } } @Overrideprotected void run( ) throws Rollback {   String nodeName =EngineServices.getNodeName( );   if (m_action == Action.CREATE)   {    System.out.println(“Executing on: ” + nodeName);    DirectedCreateObject a = new DirectedCreateObject( );    System.out.println(“Object was created on: ” + a.createdOn);   }  else   {     assert ( m_action == Action.WAIT );     //     // Onlywait on replica node     //     if (nodeName.equals(“replica”) == false)    {       m_done = true;       return;     }       //       // Waituntil an object is created from each node:       //       intcardinality = 0;       for (DirectedCreateObject dc :ManagedObject.extent(         DirectedCreateObject.class,        LockMode.READLOCK))       {         cardinality++;       }      m_done = (cardinality >= 3);     }   } }

When the preceding example is run, it creates instances of A on thereplica node. The output follows:

[replica] Executing on: replica [replica] Object was created on: replica[backup] Executing on: backup [backup] Object was created on: backup[primary] Executing on: primary [primary] Object was created on: primary

We now discuss an example of using cache groups. The example belowillustrates how to configure and create an object in a Cache Group.There is no difference between creating a type in a Cache Group and atype not in a cache group—both use new to create a new instance.

// // Configuration of type in a cache group // configuration“cacheGroup” version “1.0” type “distribution” {  configure switchadmin {   configure Distribution   {    //    // Add class B to a cache groupnamed fluency    //    CacheGroupObject    {     typeName =“programming.fluency.distributedcomputing.B”;     groupName = “fluency”;    asyncCreate = false;     asyncDestroy = false;     asyncWrite =false;    };   };  }; }; packageprogramming.fluency.distributedcomputing; import com.kabira.platform.*;import com.kabira.platform.swbuiltin.EngineServices; class B extendsManagedObject {  String createdOn; } public class CacheGroup extendsTransaction {  enum Action  {   CREATE,   WAIT,   DISPLAY  }  privateAction m_action;  private boolean m_done = false;  public static voidmain (String [ ] args) throws InterruptedException  {   CacheGroupcacheGroup = new CacheGroup( );   cacheGroup.m_action = Action.CREATE;  cacheGroup.execute( );   cacheGroup.m_action = Action.WAIT;  System.out.print(“Waiting”);   while (cacheGroup.m_done == false)   {   cacheGroup.execute( );    System.out.print(“.”);   Thread.sleep(1000);   }   System.out.println(“done”);  CacheGroup.m_action = Action.DISPLAY;   cacheGroup.execute( );  } @Override  protected void run( ) throws Rollback  {   String nodeName =EngineServices.getNodeName( );   //   // Create object on local node  //   if (m_action == Action.CREATE)   {    new B( ).createdOn =nodeName;    System.out.println(“Created object on: ” + nodeName);   }  else if (m_action == Action.WAIT)   {    if(ManagedObject.extent(B.class).size( ) < 3)    {     return;    }   m_done = true;   }   else   {    assert ( m_action == Action.DISPLAY);    ManagedObjectSet<B> extent = ManagedObject.extent(B.class);    //   // Display all references in extent. The extent contains references   // from remote objects that were pushed to the local node    //   for (B b : extent)    {     System.out.println(      “Found on ” +nodeName + “: ” + b.createdOn);    }   }  } }

When the example executes, it outputs the following (annotation addedand status messages deleted). The actual order of the messages maydiffer depending on execution timing.

# # A cache group distributed object was created on replica node #[replica] Created object on: replica [replica] Waiting.. # # A cachegroup distributed object was created on backup # [backup] Created objecton: backup [backup] Waiting.. # # A cache group distributed object wascreated on primary # [primary] Created object on: primary # # The backupnode saw all three distributed objects # [backup] .done [backup] Foundon backup: replica [backup] Found on backup: primary [backup] Found onbackup: backup # # The primary node saw all three distributed objects #[primary] Waiting.done [primary] Found on primary: primary [primary]Found on primary: replica [primary] Found on primary: backup # # Thereplica node saw all three distributed objects # [replica] done[replica] Found on replica: replica [replica] Found on replica: primary[replica] Found on replica: backup

We now discuss “unavailable node” exceptions. In particular, attemptingto access a distributed object from a remote node when the node is downwill cause this exception to be thrown:

JAVA.lang.VirtualMachineError

A remote node is detected to not be down when the following action isattempted on a distributed reference:

-   -   method invocation    -   object deletion    -   field modification    -   field access when the local cache is stale

The following example illustrates the behavior using a directed createtype that is configured for an invalid node name.

// // Configuration of a directed create type with an invalid node name// configuration “nodeDown” version “1.0” type “distribution” { configure switchadmin  {   configure Distribution   {    //    //Create all instances of class C on invalid node    //   DirectedCreateObject    {     typeName =“programming.fluency.distributedcomputing.C”;     nodeName = “invalid”;    asyncDestroy = false;     asyncWrite = false;    };   };  }; }package programming.fluency.distributedcomputing; importcom.kabira.platform.*; class C extends ManagedObject { } public classNodeDown extends Transaction {  public static void main (String [ ]args)  {   new NodeDown( ).execute( );  }  @Override  protected voidrun( ) throws Rollback  {   //   // Create an object on a node that isunavailable   // This will cause a JAVA.lang.VirtualMachineError   //  new C( );  } }

When the preceding example is executed, it outputs the following:

JAVA main class programming.fluency.distributedcomputing.NodeDown.mainexited with an exception. JAVA exception occurred:JAVA.lang.VirtualMachineError: Rethrowing system exception returned fromdispatched operation.   at com.kabira.platform.-  ManagedObject._createSMObject(Native Method)   atcom.kabira.platform.ManagedObject.-   <init>(ManagedObject.JAVA:118)  at programming.fluency.distributedcomputing.C.-  <init>(NodeDown.JAVA:17)   atprogramming.fluency.distributedcomputing.-  NodeDown.run(NodeDown.JAVA:32)   atcom.kabira.platform.Transaction.execute(Transaction.JAVA:117)   atprogramming.fluency.distributedcomputing.NodeDown.-  main(NodeDown.JAVA:23)

We now discuss locating a remote object. To initiate distributedcomputing, a reference to a remote object should be obtained. Thefollowing mechanisms are provided to access remote object references:

-   -   Directed create    -   Cache Groups    -   Remote method invocation

An external directory can also be used to store object references but,in some examples, this requires third-party software and additionalconfiguration complexity.

Directed create can be used to create a factory object on a remote node.This factory object can provide a method that returns a distributedobject instance from a remote node. This object instance can then beused on the local node as required to access remote services.

Cache groups can also be used to allow each node in a cluster to publishan object that is pushed to all other nodes. These pushed objectreferences can then be found on all nodes. The following examples showshow a cache group can be used to provide remote access to all nodes in acluster.

// // NAME // $RCSfile: InitialReferences.java,v $ // // COPYRIGHT //Confidential Property of Kabira Technologies, Inc. // Copyright 2008,2009 by Kabira Technologies, Inc. // All rights reserved. // // HISTORY// $Revision: 1.11 $ // packagecom.kabira.snippets.distributedcomputing; import com.kabira.platform.*;import com.kabira.platform.annotation.*; importcom.kabira.platform.swbuiltin.EngineServices; /** * Accessing an initialreference from a remote node. * <p> * <h2> Target Nodes</h2> * <ul> *<li> <b>domainname</b> = Fluency Development * </ul> */ public classInitialReferences extends Transaction {  /**  * Distributed object thataccesses node name  */  @Managed  public static class Reference  {   /**  * Return node name on which object was created.   * @return Node nameof node   */   public String getNodeName( )   {    returnEngineServices.getNodeName( );   }  } /** * Node */ @Distributed( cacheGroup= @com.kabira.platform.annotation.CacheGroup(groupName=“fluency”)) publicstatic class Node {  /**  * Return an object created on the local node * @return Object reference  */  public Reference getReference( )  {  InitialReferences.m_count++;   return new Reference( );  } } /** *Control program execution */ public enum Action {  /**  * Create object */  CREATE,  /**  * Wait for all nodes to create objects  */ WAITCREATE,  /**  * Query node name  */  QUERY,  /**  * Wait for allnodes to complete  */  WAITDONE } private Action m_action; privateboolean m_done = false; private static int m_count = 0; /** * Main entrypoint * * @param args Not used * @throws InterruptedExceptionInterrupted sleep */ public static void main (String [ ] args) throwsInterruptedException {  InitialReferences ir = new InitialReferences( ); ir.m_action = Action.CREATE;  ir.execute( ); System.out.println(“Waiting for creates”);  ir.m_action =Action.WAITCREATE;  while (ir.m_done == false)  {   ir.execute( );  Thread.sleep(1000);  }  System.out.println(“Creates done”);  ir.m_done= false;  ir.m_action = Action.QUERY;  ir.execute( ); System.out.println(“Waiting for nodes to complete”);  ir.m_action =Action.WAITDONE;  while (ir.m_done == false)  {   ir.execute( );  Thread.sleep(1000);  }  System.out.println(“Nodes done”); } @Overrideprotected void run( ) throws Rollback {  if (m_action == Action.CREATE) {   new Node( );  }  else if (m_action == Action.WAITCREATE)  {   intcardinality = 0;   for (Node n : ManagedObject.extent(Node.class,  LockMode.READLOCK))   {    cardinality++;   }   m_done =(cardinality >= 3);  }  else if (m_action == Action.WAITDONE)  {   if(InitialReferences.m_count < 3)   {    return;   }   m_done = true;  } else  {   assert ( m_action == Action.QUERY );   for (Node node :ManagedObject.extent(Node.class))   {    //    // Get the node name onwhich the Reference object    // was created.    //   System.out.println(“Node: ” +    node.getReference( ).getNodeName());    }   }  } }When the preceding example is executed, it outputs the following(annotation added):

[replica] Waiting for creates [replica] Creates done [replica] Node:replica [replica] Node: backup [replica] Node: primary [replica] Waitingfor nodes to complete [backup] Creates done [backup] Node: replica[backup] Node: backup [backup] Node: primary [backup] Waiting for nodesto complete [primary] Node: replica [primary] Node: backup [primary]Node: primary [primary] Waiting for nodes to complete [replica] Nodesdone [backup] Nodes done [primary] Nodes done

We now describe state conflicts. A state conflict is reported when awrite operation from a remote node detects that the data on the localnode has changed underneath it. This is possible in a distributed systembecause an object may be modified from multiple nodes in the system.This exception is thrown when a state conflict is detected:

com.kabira.platform.StateConflictError

This exception should never be caught by the application. It is used bythe system to manage state conflicts as described below.

State conflicts are handled differently depending on whether writes areconfigured to be executed asynchronously or synchronously. Whendistributed writes are configured to execute asynchronously, the stateconflict is not detected until the write is executed on the remote node.This is in a different transaction than the one that modified the objectdata. If a state conflict is detected, the update is discarded on theremote node with a log message.

When writes are configured to execute synchronously state conflicts arehandled transparently by the system. If a state conflict is detected ona remote node, an error is returned to the local node, where the cacheis invalidated so that the next field access will cause the object datato be refreshed. The transaction is then rolled back and replayed. Theapplication is never aware that a state conflict occurred.

We now discuss extents. Global extents are maintained if an object typeis configured in a cache group. As object instances are pushed out toall nodes in a cache group, the extent on the node is updated to containreferences to all instances in the distributed system.

If an object type is not configured as part of a cache group, the extenton a node only contains the instances that have been created on thatnode, or pulled to the node in some other way (directed create, remoteoperation invocation, name service, factory, etc.).

Some internal guidelines for distributed programming include:

-   -   All modifications to a distributed object should be done on one        node. This reduces the chance of state conflicts, which cause        performance degradation. The best way to enforce this is to use        methods to perform field updates. The method will execute on the        master node transparently.    -   Eliminate distributed deadlocks from an application. Distributed        deadlock detection may use a timeout to detect a deadlock. This        implies that a distributed transaction will wait the entire        value of the timeout value before a deadlock is reported. During        this period of time, the transaction is stalled.    -   Factories or directed create should be used to create an object        instance on a specific node.    -   Cache Groups should be used to discover remote references for        nodes in a cluster.    -   Evaluate which nodes application classes must be installed on.        Types configured for cache groups require that the application        class be installed on all nodes that participate in the cache        group. Applications that use directed creates and factories do        not require the application component to be installed on all        nodes in the distributed network, just the nodes on which the        object will be created.

We now discuss high-availability, including a discussion of how to addmirrored and replicated managed objects to a transactional application.We also describe how high availability services may be configured. Inparticular, to integrate mirrored and replicated objects into anapplication, the following steps should be taken:

-   -   Configure the cluster and partitions    -   Define the mirrored and replicated application objects    -   Optionally integrate a router into the application

Regarding configuration, high availability configuration information mayinclude the following:

-   -   Cluster definition    -   Partition definition    -   Change log definition

High-availability configuration may be carried out using configurationfiles. High-availability configuration defines a nested configurationblock named “ha” and also defines the following configurationinterfaces:

-   -   NodeConfiguration—defines a node in the cluster. Multiple        NodeConfiguration interfaces are supported.    -   PartitionConfiguration—defines a data partition. Multiple        PartitionConfiguration interfaces are supported.

Supported configuration values are described below

The example below illustrates how the high-availability configurationblock and interfaces may be used:

// // Define a high-availability configuration named sampleHA // This isversion 1.0 of this configuration // configuration “sampleHA” version“1.0” type “ha” {   //   // HA configuration block   //   configure ha  {     //     // Define the cluster with one or more    NodeConfiguration interfaces     //     NodeConfiguration     {    ...     };     NodeConfiguration     {       ...     };     //    // Define the application data partitions with one or more     //PartitionConfiguration interfaces     //     PartitionConfiguration    {       ...     };     PartitionConfiguration     {       ...     };  }; };

Configuration attributes supported by the HA configuration interfacesare summarized in the tables below. For example, the node configurationvalues are summarized in the following table:

Name Type Description Name Unbounded string Node name

The following table summarizes the partition configuration valuesspecific to a partition.

Name Type Description Name Unbounded string A unique partition name.This name must be unique for all configured partitions. Group Unboundstring Partition group name. minimumNumber Unsigned long Minimum rangeidentifier. maximumNumber Unsigned long Maximum range identifier.primaryNodeName Unbounded string Primary node name. backupNodeNameUnbounded string Backup node name. backupType Enumeration - Controlswhether updates to Synchronous the backup node are made in or Deferred.the caller's transaction or in a different transaction. Default value isSynchronous. backupMilliseconds Unsigned long Backup time interval inmilliseconds if backupType is Deferred. Ignored if backupType isSynchronous. Default value is 100 milliseconds. sendObjectChunkSizeUnsigned long Object chunk size to use when restoring or migratingobjects between nodes. This value controls how many objects are copiedin a single transaction during node restores and migrations. Do notchange the default value. Default value is 1000.

Optional change log configuration values in the PartitionConfigurationinterface are summarized in the table below:

Name Type Description changeLog-Scope Enumeration - Scope of changelogging. LogDisabled disables the Log- change log. LogPrimary logs onprimary node only, Disabled, LogBackup logs on backup node only, LogBoth LogPrimary, Log- logs on both the primary and backup nodes, orBackup, LogAlways logs on currently active node for LogBoth, partition.Default value is LogDisabled. LogAlways. formatterName Unbounded Changelog formatter name. Default value is X1VIL string formatter.fileNameTem-plate Unbounded The full path of the file to be used for thechange string log. This may be an absolute path or a path relative tothe node directory. The file and any missing directories will be createdas needed. Variable tokens of the form %<token> may be used to generatefile names. All of the POSIX defined tokens for strftime are supported(e.g. %Y-%m-%d %T%H:%M). There is also support for %nodeName, the nameof the Fluency node and %count, the number of times the change log hasrolled over. Default value is changelog.xml. renameOnClose Enumeration -If Enabled, causes the change log file to be renamed Enabled or when itis closed. Events that trigger renaming are Disabled rollover,configuration deactivation, stopping an application, and node restart.Renaming is not supported across devices. During the rollover, if thefileOpenMode is set to Append and the destination file exists, thelogger will append_0 to the destination name and try again, and ifdestination with_0 also exists, it will try destination with_1, and soon, till it finds the nonexisting destination_x. This prevents thesystem from accidentally overwriting an existing file. If thefileOpenMode is set to Truncate and the destination file exists, thedestination file will be overwritten during rollover. Default value isDisabled. renameTem-plate Unbounded The name to which the active logfile will be string renamed when it is closed, including the full path.Only valid if renameOnClose is set to Enabled. The rename templatesupports all of the variable tokens supported by fileNameTemplate, aswell as a special token which matches the file name portion of theoriginal file name - %original Name - the file name portion of theoriginal log file name. This token can be used to move the closed logfile into a different directory while keeping the same name. Defaultvalue is an empty string. loggingMode Enumeration - Select synchronousor asynchronous logging. A Synchronous or value of Synchronous meansthat log entries will be Asynchronous written to the log filesynchronously from the calling transaction. Asynchronous means that theentry will be written to the log file outside of the context of thecalling transaction. Default value is Synchronous. transactional-LoggerEnumeration - When set to Enabled, causes the log entry to be Enabled orwritten only upon commit of the calling transaction. Disabled If thecalling transaction is rolled back, the log entry is dropped. When setto Disabled, the log entry is always written no matter the result of thetransaction. Default value is Enabled. asyncBuffering Enumeration -Enable buffering for asynchronous logging. If Enabled or buffering isenabled, log entries will be aggregated, Disabled and written togetherevery asyncBufferingFlushIntervalSeconds seconds. Note that this optionis only valid if loggingMode is Asynchronous. Default value is Disabled.asyncBuffering-Flushlnter- Unsigned long Buffer flush interval, inseconds. When valSeconds asyncBuffering is enabled, accumulated logrecords will be written to the file system at the specified interval (inseconds). This option is mandatory if asyncBuffering is Enabled, and notvalid otherwise. Default value is 0. rolloverBySize Enumeration - Whenset to Enabled, log files are rolled over Enabled or whenever their sizeexceeds rolloverSizeBytes Disabled bytes. Default value is Disabled.rolloverSize-Bytes Unsigned long The file size, in bytes, which triggerschange log file rollover. The actual number of bytes in the log filewill normally exceed this size, as only whole records are written to thelog file. Default value is 0. rolloverByNum-Records Enumeration - Whenset to Enabled, log files are rolled over when Enabled or the number oflog records written to the file reaches Disabled rolloverNumRecords.Default value is Disabled. rolloverNumRecords Unsigned long The numberof records which triggers log file rollover. Default value is 0.rolloverBylnterval Enumeration - When set to Enabled, log files arerolled over every Enabled or rolloverlntervalSeconds seconds. Defaultvalue is Disabled Disabled. rolloverlnter-valSeconds Unsigned long Logfiles are rolled over every rolloverlntervalSeconds seconds. Defaultvalue is 0. fileCreateMode Unbounded The permissions to be used whencreating log files. string The format is an octal string of the formOxxx, as defined by the P051K chmod 0 command. Note that the actualpermissions on the file will be modified by the process's umask. Defaultvalue is 0644. directoryCreate-Mode Unbound string The permissions to beused when creating directories. The format is an octal string of theform Oxxx, as defined by the P051K chmod 0 command. Note that the actualpermissions on the directories will be modified by the process's umask.Default value is 0755. fileSyncMode Enumeration - The synchronizationlevel to set when opening log Un-synchronized, files. The valuesSynchronized and Synchronized, or SynchronizedDataOnly correspond to theP051K Synchronized open 0 system call flags 0_SYNC and O_DSYNC, DataOnlyrespectively. Default value is Synchronized. fileOpenMode Enumeration -The action to be taken when opening a log file Truncate or which alreadyexists. If the value is Append, the Append contents of the file will bepreserved, and new log records written to the end of the file. If thevalue is Truncate, the contents of the file will be overwritten. Defaultvalue is Append. allowEmptyLog-Files Enumeration - When set to Enabled,empty log files are created Enabled or upon close or rollover if thereare no records in the Disabled log file. Otherwise, no file is createdunder those conditions. Default value is Enabled. emptyLogFile-ContentEnumeration - When set to Header Footer, empty log files include Emptyor the header(s) and footer(s). If the value is Empty the Header- emptylog files do not include a header or a footer. Footer

An example of a highly available configuration file follows:

configuration “ha” version “1.0” type “ha” {  configure ha  {   //   //Configure a primary, backup, and replica node   //   NodeConfiguration {name = “primary”; };   NodeConfiguration { name = “backup”; };  NodeConfiguration { name = “replica”; };   //   // Define a singlepartition   //   PartitionConfiguration   {    name = “fluency”;   group = “fluency”;    primaryNodeName = “primary”;    backupNodeName= “backup”;    minimumNumber = 0;    maximumNumber = 100;   sendObjectChunkSize = 5;    //    // Change Log Configuration    //   changeLogScope = LogBoth;    fileNameTemplate =   “../../logs/changelogs/%nodeName/%m%d_%count.xml”;    fileOpenMode =Append;    directoryCreateMode = “0755”;    fileCreateMode = “0666”;   rolloverBySize = Disabled;    rolloverSizeBytes = 0;   rolloverByInterval = Disabled;    rolloverIntervalSeconds = 0;   rolloverByNumRecords = Enabled;    rolloverNumRecords = 1000;   renameOnClose = Enabled;    renameTemplate =  “../../logs/changelogs/%nodeName/complete/%m%d_%count.xml”;   loggingMode = Synchronous;    transactionalLogger = Enabled;   fileSyncMode = Unsynchronized;   };  }; };

We now discuss defining mirrored and replicated managed objects.Mirrored and replicated managed objects are defined by extending fromthe appropriate parent type. The following example shows how a mirroredmanaged object and a replicated managed object may be defined andcreated.

package programming.fluency.highavailability; importcom.kabira.platform.Transaction; import com.kabira.platform.ha.*; // //This is a Mirrored Managed Object that will be created in // Partitiongroup “fluency” with a partition number of 0. The // applicationidentifier is set to a null to use the default value. // class B1extends MirroredObject {   B1( )   {     super (“fluency”, 0, null);   }} // // This is a Replicated Managed Object that will be created in //Partition group “fluency” with a partition number of 0. The //application identifier is set to a null to use the default value. //class B2 extends ReplicatedObject {   B2( )   {     super (“fluency”, 0,null);   } } public class B extends Transaction {   public static voidmain (String [ ] args)   {     new B( ).execute( );   }   @Override  protected void run( ) throws Rollback   {     //     // Create amirrored managed object     //     new B1( );     //     // Create areplicated managed object     //     new B2( );   } }

It is noted that mirrored and replicated managed objects have the samelife cycle as any managed object.

We now discuss application identifiers. Replicated and mirrored managedobjects have an optional application defined identifier that can bespecified when an object is created. A unique index is maintained forthis identifier on all nodes in the HA cluster. This index is maintainedduring failover, restore, and migrations. The application identifier isunique across all mirrored and replicated object instances.

Specifying a non-unique identifier value when creating an object willcause the create to fail with the following exception:

# # An attempt to create an object with a non-unique application #identifier throws this exception #com.kabira.platform.ObjectNotUniqueError

The following example demonstrates the behavior of duplicateidentifiers.

package programming.fluency.highavailability; importcom.kabira.platform.ha.MirroredObject; import com.kabira.platform.*;class E1 extends MirroredObject {  E1 (String identifier)  {   super(“fluency”, 0, identifier);  } } class E2 extends Thread {  intnumberLoops = 10;  @Override  public vVoid run( )  {   int i;   E3 e3 =new E3( );   for (i = 0; i < numberLoops; i++)   {    e3.identifier =“” + i;    e3.execute( );   }  } } class E3 extends Transaction { String identifier;  @Override  protected void run( ) throws Rollback  {  try   {    new E1(identifier);   }   catch (ObjectNotUniqueError ex)  {    System.out.println(     “Thread: ” + Thread.currentThread().getName( )     + “ ” + ex.getMessage( ));   }  } } public class Eextends Transaction {  public static void main (String [ ] args) throwsInterruptedException  {   //   // Start two threads - both threads areattempting to create   // objects using the same identifier - first onedoing the   // create wins. The other thread receives aObjectNotUniqueError   // exception.   //   E2 one = new E2( );   E2 two= new E2( );   one.start( );   two.start( );   //   // Wait for thethreads to exit   //   one.join( );   two.join( );   //   // Displaydata in shared memory   //   new E( ).execute( );  }  @Override protected void run( ) throws Rollback  {   ManagedObjectSet<E1> extent= ManagedObject.extent(E1.class);   for (E1 e1 : extent)   {   System.out.println(e1.identifier);   }  } }

When the preceding example runs, it outputs as follows (annotationadded). The exact thread number will vary.

Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:1. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:2. Key data: [ identifier = “0” ]Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:5. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:3. Key data: [ identifier = “1” ]Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:9. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:4. Key data: [ identifier = “2” ]Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:14. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:6. Key data: [ identifier = “3” ] 87Application Identifier Thread: Thread-2 Duplicate found for key‘ha::BaseImpl::ByIdentifier’ in programming/fluency/highavailability/E1,instance 1372378:250624:14560768793792062867:15. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:7. Key data: [ identifier = “4” ]Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:16. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:8. Key data: [ identifier = “5” ]Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:17. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:10. Key data: [ identifier = “6” ]Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:18. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:11. Key data: [ identifier = “7” ]Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:19. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:12. Key data: [ identifier = “8” ]Thread: Thread-2 Duplicate found for key ‘ha::BaseImpl::ByIdentifier’ inprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:20. Duplicate isprogramming/fluency/highavailability/E1, instance1372378:250624:14560768793792062867:13. Key data: [ identifier = “9” ] ## 10 unique objects were created in shared memory # 5 0 6 1 7 2 8 9 3 4

If the application does not require a unique identifier, a value of nullcan be specified for the identifier in the constructor. This will causethe system to chose a globally unique identifier for the object.

Both replicated and mirrored managed objects support aselectUsingByIdentifier method that is used to find the specifiedobject. This method has the following signature:

public static Base selectUsingByIdentifier(JAVA.lang.String identifier,LockMode lockMode)

The parameters to this method are set forth in the following table:

Name Description identifier Application specified identifier. lockModeSpecify the transaction lock to be taken on the object. Valid values areLockMode.NoLock, LockMode.ReadLock, and LockMode.WriteLock.

The return value from the selectUsingByIdentifier method is a validobject instance if an object with the specified identifier is found. Thereturn value is a null object handle if an object with the specifiedidentifier is not found.

We now describe an example of using the application identifier.

package programming.fluency.highavailability; importcom.kabira.platform.ha.*; import com.kabira.platform.Transaction; importcom.kabira.platform.LockMode; importcom.kabira.platform.ObjectNotUniqueError; class F1 extendsMirroredObject {  F1 (String identifier)  {   super (“fluency”, 0,identifier);  } } public class F extends Transaction {  public staticvoid main (String [ ] args)  {   new F( ).execute( );  }  @Override protected void run( ) throws Rollback  {   //   // Create an instanceof F1 with an identifier value of “one”   // This can throwObjectNotUnique if an object with this identifier   // is alreadycreated   //   new F1(“one”);   //   // Find the instance of F1 justcreated   //   F1 one = (F1)F1.selectUsingByIdentifier(“one”,  LockMode.ReadLock);   System.out.println(“Selected: ” +one.identifier);   //   // Create an instance of F1 using the defaultidentifier   //   new F1(null);   //   // The create and select are donein a while loop to   // handle the case where a delete was done in adifferent   // thread after the new throws an exception, but before   //the select is executed.   //   F1 two = null;   while (two == null)   {   try    {     two = new F1(“two”);    }    catch (ObjectNotUniqueErrorex)    {     two = (F1)F1.selectUsingByIdentifier(“two”,   LockMode.ReadLock);    }   }  System.out.println(“Selected: ” +two.identifier);  } }

Executing the preceding example results in the following output

-   Selected: one-   Selected: two

We now discuss routing. Updates to mirrored or replicated managedobjects occur on the current active master node for the object. TheRoute and DeliveryNotifier classes provide the mechanism totransparently route data between nodes to ensure that object updates aredone on the current active master for a mirrored or replicated managedobject. The routing functionality can also be used by applications forapplication specific reasons that do not involve modification ofmirrored or replicated managed objects.

The Route class delivers application specified data to aDeliveryNotifier by name. The name of the DeliveryNotifier is unique ona node. However, the name does not have to be unique across all nodes inthe cluster. The named DeliveryNotifier that is the target of a routerequest can exist on the local or any remote node. The location of theDeliveryNotifier is transparent to the application using the Routeclass. During application initialization delivery, notifiers should becreated on all nodes that will be the target of route requests.

The Route class supports:

-   -   routing to the current active master node for a partition    -   routing to a specific node        These routing services allow an application to easily return a        response to a node that initiated a request, by sending some        data to an application.

The below example shows the use of the Route class and aDeliveryNotifier to send some application specific data between twonodes. The initial routing is done by a partition identifier and theresponse is returned using the source node name.

The following example illustrates routing:

// // NAME // $RCSfile: Routing.java,v $ // // COPYRIGHT // ConfidentialProperty of Kabira Technologies, Inc. // Copyright 2008 by KabiraTechnologies, Inc. // All rights reserved. // // HISTORY // $Revision:1.5 $ // package com.kabira.snippets.highavailability; importjava.util.logging.Level; import java.util.logging.Logger; importcom.kabira.platform.ha.*; import com.kabira.platform.Transaction; importcom.kabira.platform.ManagedObject; importcom.kabira.platform.swbuiltin.EngineServices; /** * Routing applicationdata to active node for a partition * <p> * <h2> Target Nodes</h2> *<ul> * <li> <b>domainname</b> = Fluency Development * </ul> */ publicclass Routing extends Transaction {  /**  * Routing notifier  */ publicstatic class Notifier extends DeliveryNotifier {  Notifier(String name) {   super (name);  }  @Override  public void deliverToPartition( String sourceNodeName,  PartitionId targetPartition,  Object data)throws RoutingError  {   String request = “ Request: ” + (String) data;  String nodes = “Source Node: ” + sourceNodeName    + “ Target Node:” + EngineServices.getNodeName( );   System.out.println(nodes +request);   //   // Return a response to the source node   //  Route.toNode(Routing.notifierName, sourceNodeName,   “How are you?”);  //   // Let main know we are done   //   Routing.done = true;  } @Override  public void deliverToNode(   String sourceNodeName,   Objectdata) throws RoutingError  {   String response = “ Response: ” +(String) data;   String nodes = “Source Node: ” + sourceNodeName    + “Target Node: ” + EngineServices.getNodeName( );  System.out.println(nodes + response);   //   // Let main know we aredone   //   Routing.done = true;  } } /** * Control program exceution */public enum Action {  /**  * Create routing notifier  */ CREATENOTIFIER,  /**  * Send routing request  */  SENDREQUEST,  /**  *Delete routing notifier  */  DELETENOTIFIER } static final StringnotifierName = “mynotifier”; static volatile boolean done = false;private String m_engineName; private Action m_action; private Notifierm_notifier; /** * Main entry point * @param args Not used * @throwscom.kabira.platform.ha.RoutingError * @throwsjava.lang.InterruptedException */ public static void main(String [ ]args)  throws RoutingError, InterruptedException {  Routing routing =new Routing( );  routing.m_action = Action.CREATENOTIFIER; routing.execute( );  routing.m_action = Action.SENDREQUEST; routing.execute( );  //  // Wait here until done - we retry the sendrequest  // on the replica node. this handles the case where  // theprimary node hadn't created a notifier yet  //  while (done == false)  {  Thread.sleep(2000);   if (routing.m_engineName.equals(“replica”) ==true)   {    routing.execute( );   }  }  routing.m_action =Action.DELETENOTIFIER;  routing.execute( ); System.out.println(routing.m_engineName + “ exiting”); } @Overrideprotected void run( ) throws Rollback {  m_engineName =EngineServices.getNodeName( );  if (m_action == Action.CREATENOTIFIER) {   m_notifier = new Notifier(notifierName);   return;  }  if (m_action== Action.DELETENOTIFIER)  {   ManagedObject.delete(m_notifier);   m_notifier = null;    return;  }  assert ( m_action ==Action.SENDREQUEST );  //  // If backup node we can exit immediately  // if (m_engineName.equals(“backup”) == true)  {   Routing.done = true;  return;  }  //  // Route a message only from the replica node  //  if(m_engineName.equals(“replica”) == false)  {   return;  } System.out.println(“Routing request”);  //  // Route a request to thepre-configured partition  //  PartitionId partitionId = new PartitionId();  partitionId.group = “fluency”;  partitionId.number = 0;  Stringrequest = “Hello?”;  try  {   Route.toPartition(notifierName,partitionId, request);  }  catch (RoutingError ex)  {  Logger.getLogger(   Routing.class.getName( )).log(Level.SEVERE,ex.getMessage( ), ex);  } }When the preceding example is run, the following output is generated(annotation added and informational messages removed). The actual outputmay vary based on execution timing differences.

# # Request sent from replica to primary node # [replica] Routingrequest # # Backup main is exiting. The code executing on the backupnode does # not participate in the routing example # [backup] backupexiting # # This is the replica node receiving the response from theprimary. It is # output before the primary message because of the wayoutput is received from remote nodes # [replica] Source Node: primaryTarget Node: replica Response: How are you? # # The replica is exitingafter receiving the response from the primary node # [replica] replicaexiting # # This is the primary node receiving the request from thereplica # [primary] Source Node: replica Target Node: primary Request:Hello? # # The primary node is exiting after sending a response to thereplica node # [primary] primary exiting

We now discuss partitioning of application data. Application data can bepartitioned into one or more partitions by specifying the partitiongroup and number when a mirrored or replicated managed object iscreated. The com.kabira.ha.Base class, which is the base class for bothMirrored and Replicated Managed Objects, defines this publicconstructor:

public Base(   JAVA.lang.String partitionGroup, // Partition group in  which to create object   long partitionNumber, // Partition number touse for object   JAVA.lang.String identifier) // Application specific  identifier for object

The Partition specified when an object is created is to be configured onthe local node. The decision on which partition should be associatedwith a Mirrored or Replicated Managed object may be based on anapplication specific criteria. For example all customers on the westcoast may be in a partition named WEST, while all customers on the eastcoast may be in a partition named EAST.

The example below illustrates partitioning application data:

// // HA configuration data to define two partitions - EAST and WEST //configuration “ha” version “2.0” type “ha” {  configure ha  {  //  //Configure a primary, backup, and replica node  //  NodeConfiguration {name = “primary”; };  NodeConfiguration { name = “backup”; }; NodeConfiguration { name = “replica”; };  //  // Define EAST partition //  PartitionConfiguration  {   name = “eastcoast”;   group = “EAST”;  primaryNodeName = “primary”;   backupNodeName = “backup”;  minimumNumber = 0;   maximumNumber = 100;   sendObjectChunkSize = 5;  //   // Change Log Configuration   //   changeLogScope = LogBoth;  fileNameTemplate =  “../../logs/changelogs/%nodeName/%m%d_%count.xml”;   fileOpenMode =Append;   directoryCreateMode = “0755”;   fileCreateMode = “0666”;  rolloverByNumRecords = Enabled;   rolloverNumRecords = 1000;  renameOnClose = Enabled;   renameTemplate =  “../../logs/changelogs/%nodeName/complete/%m%d_%count.xml”;  loggingMode = Synchronous;   transactionalLogger = Enabled;  fileSyncMode = Unsynchronized;  };   //   // Define WEST partition  //   PartitionConfiguration   {    name = “westcoast”;    group =“WEST”;    primaryNodeName = “primary”;    backupNodeName = “backup”;   minimumNumber = 0;    maximumNumber = 100;    sendObjectChunkSize =5;    //    // Change Log Configuration    //    changeLogScope =LogBoth;    fileNameTemplate =   “../../logs/changelogs/%nodeName/%m%d_%count.xml”;    fileOpenMode =Append;    directoryCreateMode = “0755”;    fileCreateMode = “0666”;   rolloverByNumRecords = Enabled;    rolloverNumRecords = 1000;   renameOnClose = Enabled;    renameTemplate =   “../../logs/changelogs/%nodeName/complete/    %m%d_%count.xml”;   loggingMode = Synchronous;    transactionalLogger = Enabled;   fileSyncMode = Unsynchronized;   };  }; }; // // Application datapartitioning example // package programming.fluency.highavailability;import com.kabira.platform.LockMode; importcom.kabira.platform.ha.MirroredObject; importcom.kabira.platform.Transaction; class Customer extends MirroredObject { Customer (String partitionGroup, String identifier)  {   super(partitionGroup, 0, identifier);   System.out.println(   “Assigningcustomer ” + identifier + “ to group: ” + partitionGroup);  } } publicclass D extends Transaction {  public static void main (String [ ] args) {   new D( ).execute( );  }  @Override  protected void run( ) throwsRollback  {   //   // Create Fred in the west partition group   //  Customer fred = new Customer(“WEST”, “Fred”);   //   // Create Barneyin the east partition group   //   Customer barney = newCustomer(“EAST”, “Barney”);   //   // Find Fred and Barney   //   fred =(Customer)Customer.selectUsingByIdentifier(    “Fred”,LockMode.ReadLock);   barney =(Customer)Customer.selectUsingByIdentifier(    “Barney”,LockMode.ReadLock);   System.out.println(fred.identifier + “ is in ” +fred.partitionGroup);   System.out.println(barney.identifier + “ is in” +   barney.partitionGroup);  } }

When the preceding example is run, it creates the following output:

Assigning customer Fred to group: WEST Assigning customer Barney togroup: EAST Fred is in WEST Barney is in EAST

We now describe partition state change notifiers. In some cases, anapplication should be notified when a partition state changes. This issupported using:

public abstract class com.kabira.platform.ha.PartitionStateNotifier {  abstract void stateTransition(     Partition partition,    PartitionState oldState,     PartitionState newState); }

An application can create an instance of a PartitionStateNotifier oneach node where it is interested in notifications of Partition statechanges. The stateTransition method will be called for each state changefor all partitions to which it is registered.

The following example shows a simple implementation that monitorsPartition state changes.

package programming.fluency.highavailability; importcom.kabira.platform.LockMode; import com.kabira.platform.ha.*; importcom.kabira.platform.Transaction; class G1 extends PartitionStateNotifier{  @Override  public void stateTransition(   Partition partition,  PartitionState oldState,   PartitionState newState)  {   Stringmessage = “Partition: ” + partition.name + “ transitioning ” +    “from” + oldState + “ to ” + newState + “ now hosted on ” +   partition.primaryNodeName;   System.out.println(message);  } } publicclass G extends Transaction {  enum Action  {   CREATE,   WAIT,   DELETE }  private Action m_action;  private boolean m_onLocalNode = true; private Partition m_partition;  private G1 m_g1;  public static voidmain (String [ ] args) throws InterruptedException  {   G  g = new G( );  g.m_action = Action.CREATE;   g.execute( );   //   // Wait here forPartition to failover to remote node   //   g.m_action = Action.WAIT;  while (g.m_onLocalNode == true)   {    g.execute( );   System.out.println(“Waiting for partition to failover”);   Thread.sleep(10000);   }   //   // Wait here for Partition to berestored from remote node   //   g.m_action = Action.WAIT;   while(g.m_onLocalNode == false)   {    g.execute( );   System.out.println(“Waiting for partition to be restored”);   Thread.sleep(10000);   }   g.m_action = Action.DELETE;   g.execute();  }  @Override  protected void run( ) throws Rollback  {   if(m_action == Action.CREATE)   {    m_g1 = new G1( );    //    // Get thepartition we are interested in    //    m_partition =Partition.selectUsingByName(“fluency”,   LockMode.ReadLock);    //    //Register our notifier    //    m_partition.setStateNotifier(m_g1);   }  else if (m_action == Action.WAIT)   {    //    // See if the partitionis still hosted on the local node    //    m_onLocalNode =m_partition.isHostedOnLocalNode( );   }   else   {    assert ( m_action== Action.DELETE );    //    // Clear our notifier    //   m_partition.clearStateNotifier(m_g1);    m_g1.delete( );   }  } }

When the preceding example is run, it outputs the following (annotationadded):

Waiting for partition to failover # # fluency partition was failed overto the backup node # Partition: fluency transitioning from Migrating toHostedOnPrimary now hosted on backup Waiting for partition to failover ## fluency partition was restored to the primary node # Partition:fluency transitioning from Migrating to HostedOnPrimary now hosted onprimary Waiting for partition to be restored

We now describe the use of timers for high availability. A highlyavailable timer provides transparent fail-over to a backup node if theprimary node fails. It also provides transparent timer services duringnode restoration and migration. The timer services are implemented as anotifier. An application inherits from the timer notifier interface andprovides an implementation of the timerNotifier operation to use thetimer service.

HA timers are transactional. If a timer is executing on a primary nodebut it does not commit before a primary node failure, the timer will beexecuted on the backup node following fail-over. HA timers are providedby the kabira.platform.ha.TimerNotifier class. The TimerNotifier is amirrored object. It has a primary and a backup node and is associatedwith a partition. The timer can be controlled only on the current activenode for the partition associated with the timer. The timer notifierwill also only trigger on the currently active node. The objectparameter to the timerNotifier operation must also be a Mirrored Managedobject in the same partition as the timer notifier. This is so that thisobject is available on both the primary and backup nodes for the timer.

The ha::TimerId is a unique identifier for the timer on both the primaryand backup nodes. The application can rely on this identifier being thesame on both nodes. Timers may be started using the number of secondsfrom the current time, i.e. a relative, not an absolute time. The timerfires when this time expires. The relative time is transmitted to thebackup node for a timer and the current time on the backup node is usedto calculate when the timer should fire. This minimizes the impact ofclock drift between the primary and backup nodes. However, it isstrongly recommended that clocks be synchronized between the primary andbackup nodes.

When a primary node fails, any pending timers are automaticallyrestarted on the backup node. One-shot timers will only be executed onthe backup node if they have not executed on the primary node before thefailure. They will be executed at the initially scheduled time. Arecurring timer will execute on the backup node at the next scheduledtime. It will then continue to execute on the backup node until theprimary node is restored. If a recurring timer was missed due to a delaybetween the primary failure and the backup node taking on the work,these scheduled timer executions will be dropped—there are no “makeup”executions for recurring timers.

When a primary node is restored, any active timers on the backup nodewill be cancelled on the backup node and restarted on the primary node.The same notifier execution rules as described for fail-over aboveapply. Migrating a partition that contains active timers will cause thetimer to be canceled on the old primary node and restarted on the newprimary node. The same is true if the backup node was migrated. The samenotifier execution rules as described for fail-over above apply.

The following example illustrates how a highly available timer iscreated and terminated.

package programming.fluency.highavailability; importcom.kabira.platform.Transaction; importcom.kabira.platform.ManagedObjectSet; import com.kabira.platform.ha.*;// // Mirrored object passed to timer notifier // class C1 extendsMirroredObject {  C1( )  {   super (“fluency”, 0, null);  }  int count;} // // Timer notifier // class Notifier extends TimerNotifier {  //  //Timer notifier must be in same partition as the  // object passed to thenotifier  //  Notifier( )  {   super (“fluency”, 0, null);  }  @Override public void timerNotify(String timerId, MirroredObject object)  {   C1c1 = (C1) object;   c1.count += 1;   System.out.println(“Timer Id:” +timerId + “ Value: ” + c1.count);  } } public class C extendsTransaction {  enum Action  {   START,   TERMINATE  }  private Actionm_action;  public static void main (String [ ] args) throwsInterruptedException  {   C c = new C( );   c.m_action = Action.START;  c.execute( );   //   // Wait for timer to fire a few times   //  Thread.sleep(10000);   c.m_action = Action.TERMINATE;   c.execute( ); }  @Override  protected void run( ) throws Rollback  {   if (m_action== Action.START)   {    Notifier notifier = new Notifier( );    C1 c1 =new C1( );    System.out.println(“Starting one second recurring timer”);   notifier.startRecurring(1, c1);   }   else   {    //    // Stoptimer - just delete the notifier    //    ManagedObjectSet<Notifier>extent =    Notifier.extent(Notifier.class);    for (Notifier notifier :extent)    {     System.out.println(“Stopping one second recurringtimer”);     notifier.delete( );    }   }  } }

When the preceding example is run, it results in the following output(annotations added).

# # Timer started # Starting one second recurring timer # # Timernotifier called # Timer Id:primary:442381631492 Value: 1 TimerId:primary:442381631492 Value: 2 Timer Id:primary:442381631492 Value: 3Timer Id:primary:442381631492 Value: 4 Timer Id:primary:442381631492Value: 5 Timer Id:primary:442381631492 Value: 6 TimerId:primary:442381631492 Value: 7 Timer Id:primary:442381631492 Value: 8Timer Id:primary:442381631492 Value: 9 # # Timer terminated # Stoppingone second recurring timer

We now describe failure exposure, including possible data loss underdifferent backup policies and the keep-alive feature for detectingremote node outages. For example, with regard to synchronous updates,synchronous updates will only lose any non-committed Mirrored orReplicated object updates. No committed work is lost.

Inbound communications buffers that have not been processed are alsolost. Some network buffers are configurable. A smaller network buffersize implies lower exposure to data loss. Even this small risk of dataloss can be avoided if the client of the application has a protocolacknowledgement and includes retry logic if no acknowledgement isreceived. If the client application resends the request, nothing islost. However, care should be taken to handle duplicates.

Deferred updates will lose data queued for update. The amount of datathat is queued is controlled by the time interval of the backup. Smallerintervals minimize the possible data loss. This lost data was committedby the application on the primary node.

Keep-alive is supported between all nodes in a cluster. Keep-aliverequests and responses are used to actively determine whether a remotenode is still reachable. If a keep-alive response is not received from aremote node within a configurable amount of time the node is considereddown. This will cause all routing to that node to be redirected to thebackup node for that unavailable node.

We now describe monitoring applications, particularly duringdevelopment. In one example, a management console—Kabira Manager—is usedto control and monitor nodes. The following steps may be taken to startmonitoring the Fluency development server environment.

-   1. Connect to the URL on the VMWare image start-up screen with a Web    Browser.-   2. Log into the management console using a username of guest and a    password of fluency.-   3. Log into the Fluency Development domain using a username of guest    and a password of fluency.

These steps are described in more detail below.

An Object Monitor provides viewing of Managed Objects in shared memory.The object monitor may be accessed, for example, for each applicationnode from the VMWare Welcome Page: Monitor Access on Welcome ScreenEvents

Nodes generate events for exceptional conditions. These events areavailable in:

-   -   Node log files.    -   Domain Manager event cache    -   Domain Manager event monitor

No matter where events are viewed, they have the same content:

-   -   Time Stamp—time event occurred    -   Event Topic—topic on which event was published    -   Event Identifier—unique event identifier    -   Event Originator—a unique identifier for the event originator    -   Message—a textual message

In addition, events displayed from the Domain Manager event cache ormonitor also contain the node name that generated the event. Here is aexample event displayed in the Domain Manager event monitor:

Node Name = primary Date Time = 2008-09-10 12:57:38 Event Topic =kabira.kts.security Event Identifier =switchadmin::EventIdentifiers::OperatorActionSucceeded Event Originator= switchadmin::PluginServiceImpl:1 (344579:8358104:7100:1 offset67017096)Message=Administrator command [display] on target [security] executed byprincipal [guest] succeeded.

The Domain Manager event cache provides a historical cache of all eventsraised by nodes being managed by a domain manager. The event cachesupports the following filters:

-   -   Node Name—only show events for a specific node.    -   Event Topic—only show events for a specific event topic.    -   Event Identifier—only show events with a specific event        identifier.    -   Event Originator—only show events from a specific originator    -   Contains—only show events that contain a specific phrase.    -   Start Time to End Time Range—only show events between specific        start and end times.

The end time can be omitted to show all events from a specific starttime.

The Domain Manager Event Monitor displays events real time as theyoccur.

We now describe an example of a deployment tool may be used duringdevelopment to deploy applications to nodes. The deployment tool can beused from the command line or via a JAVA IDE. In one example, thedeployment tool is named fluency.jar.

The general syntax for using the deployment tool is:

JAVA -jar fluency.jar [options] <target> [application parameters] JAVA-jar fluency.jar [options] help JAVA -jar fluency.jar [options] displayservices

fluency.jar is specified as the first −jar option. This ensures that thedeployment tool gets control during the execution of the application andmanages execution and debugging of the application on a node. Attemptingto execute an application that uses “fluency” classes without specifyingthe fluency.jar file as the first −jar option will cause a JAVA stackdump (such as shown in the following example) because the classes cannotexecute outside of the transaction processing JVM:

EXAMPLE

Exception in thread “main” JAVA.lang.SecurityException: Prohibitedpackage name: JAVA.lang atJAVA.lang.ClassLoader.preDefineClass(ClassLoader.JAVA:479) atJAVA.lang.ClassLoader.defineClass(ClassLoader.JAVA:614) atJAVA.security.SecureClassLoader.defineClass(SecureClassLoader.-JAVA:124) atJAVA.net.URLClassLoader.defineClass(URLClassLoader.JAVA:260) atJAVA.net.URLClassLoader.access$100(URLClassLoader.JAVA:56) atJAVA.net.URLClassLoader$1.run(URLClassLoader.JAVA:195) atJAVA.security.AccessController.doPrivileged(Native Method) atJAVA.net.URLClassLoader.findClass(URLClassLoader.JAVA:188) atJAVA.lang.ClassLoader.loadClass(ClassLoader.JAVA:306) atsun.misc.Launcher.loadClass(Launcher.JAVA:268) atJAVA.lang.ClassLoader.loadClass(ClassLoader.JAVA:251) atJAVA.lang.ClassLoader.loadClassInternal(ClassLoader.JAVA:319) atpojopersistent.Main.main(Main.JAVA:23)

[options] may be any combination of JVM options or Fluency options. TheFluency JVM supports the same options as the Sun JAVA SE 6 JVM. See, forexample,http://JAVA.sun.com/JAVAse/6/docs/technotes/tools/windows/JAVA.html. JVMoptions are prefixed with a “−”, while Fluency options are of the formname=value. <target> is the application jar file or class that will beexecuted on the Fluency node. [application parameters] are applicationspecific parameters that are passed to the application program's main.

The help command displays the usage message. The display servicescommand is used to query MDNS service discovery for Fluency services onthe network. The display services command only works if MDNS servicediscovery is configured on the local machine.

The following table summarizes supported deployment tool options:

Option Description adminport The [adminport] of the Fluency node thatshould be used to run the application. autoconfigure This option, whengiven a value of true, requests that the Fluency node load and activatenode configuration files before the application starts, and deactivate/remove those configurations when the application terminates (default:false). debug A boolean flag indicating whether diagnostic output isrequired (default: false). detailed A boolean flag indicating whetherthe display service& command output should contain detailed results(default: false). displayversion A boolean flag indicating whether theFluency version information should be displayed (default: true).domainname The name of the domain that the application is to run on.When this option is used, the deployment tool must connect to a KabiraDomain Manager node which is managing the given domain. The applicationwill execute on all nodes in the domain. domaingroup The name of thedomain group that the application is to run on. When this option isused, the deployment tool must connect to a Kabira Domain Manager nodewhich is managing the given domain group. The application will executeon all nodes in the domain group. domainnode The name of the domain nodethat the application is to run on. When this option is used, thedeployment tool must connect to a Kabira Domain Manager node which ismanaging the given domain node. The application will execute on thespecified node. hostname The [hostname] hosting the Fluency node thatshould be used to run the application (default: localhost). password The[password] to use when authenticating [username] during the connectionto the Fluency node. remotedebug If <value> is true~, require the JVIVIhosting the application to enable remote debugging (default: false forPRODUCTION nodes, true for DEVELOPMENT nodes). remotedebugport Thedebugger agent port, to be used by the JYIVI to listen for remotedebugger clients (default: randomly chosen by the JVIVI). reset Thisoption, when given a value of tru&, requests that all Java objects onthe node be deleted before the application begins execution (default:true). servicename The [servicename] of the Fluency node that is to beused to run the application. This option may be used instead of[adminport] and [hostname]. This option only works if MDNS servicediscovery is configured on the local machine. suspend If <value> istrue~, require the JVIVI to suspend execution before main 0 is calledduring remote debugging. This option only applies if remotedebug = trueis specified (default: false). timeout The number of seconds to waitwhile resolving [servicename] with MDNS (default: 10). username The[username] to use when connecting to the Fluency node. The specifiedvalue must identify a principal with administrative privileges on thegiven node. x5O9credential The X509 certificate keystore file to use forauthentication. If given, the [password] parameter is required, andshould be the keystore password. x5O9credentialalias The alias of theusers X509 certificate in the keystore specified by the [x5O9credential]option (default: mykey).

The reset option provides development support for changing the shape ofManaged Objects in shared memory. It has no affect to non-managed Javaobjects. The reset option only affects the node on which it wasexecuted. To reset types in a distributed or highly availableenvironment, the same reset option value must be executed on all nodes.

Examples of changing the shape of a Managed Objects are:

-   -   adding a field to a class    -   removing a field from a class    -   changing the type of a field in a class    -   changing the inheritance hierarchy

Fluency detects when the shape of a Managed Object changes and fails theload of the changed class definition if reset=false. For example, thefollowing example may be run twice—once with m_string not commented out,and then again with m_string commented out:

115 [prmary] Java main class prograinin ng . fluency. reference. Shape.main exited with an exception. [primary] Java exception occurred: Auditof class [programming.fluency. reference.ShapeChange] failed:      Typedid not match. New type name programming.fluency.reference.ShapeChange -     existing type name programming.fluency.reference.ShapeChange.Changed values      :numberSlots:objectSze:      the class will not beloaded. [primary] atcom.kabira.platform.classloader.ClassLoader.createKTPTypeDescrptor(Native Method) [primary] atcom.kabira.platform.classloader.ClassLoader.deflneManagedClass(ClassLoader . java: 642) [primary] atcom.kabira.platform.classloader.ClassLoader.flndClass(ClassLoader.java:302)[primary] atcom.kabira.platform.classloader.ClassLoader.loadClass(ClassLoader.java:228)[primary] at java.lang.ClassLoader.loadClass(ClassLoader.java: 251)[primary] atjava.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [primary]at programming.fluency.reference.Shape.run(Shape.java:37) [primary] atcom.kabira.platform.Transaction.execute(Transacton.java:132) [primary]at programming.fluency.reference.Shape.maTh(Shape.java:31) INFO:application [programming.fluency.reference.Shape6] running on node[primary] exited with status [−1] INFO: Run of distributed application[programming.fluency.reference.Shape6] complete.

Setting reset=true (the default value) will avoid this exception. Whenan application is executed with reset=true the following happens:

-   -   1. All Managed Objects in shared memory are deleted    -   2. The type definition of the Managed Objects is removed.    -   3. The type definition of the Managed Objects is recreated using        the new class definition.

When Replicated, Mirrored, or Distributed Managed Objects are used in anapplication, the type definition for these classes are pushed to allnodes in a cluster. To ensure that the type definitions stay consistenton all nodes, the same value for the reset option must be sent to allnodes. This may be accomplished using the Distributed Developmentfeatures described above.

When the Fluency deployment tool is executed it looks for the followingfile:

<user home directory>/.fluency/options

If this file exists, any deployment tool command line options in theoptions file are used. Command line options specified in the optionsfile have the same affect as the same command line option specified onthe command line. Options on the command line override the same optionin the options file. For example if the command line contains −jarfluency.jar debug=true and the options file contains debug=false, adebug value of true is used for the application execution.

The options file follows the format below.

# # Any line starting with ‘#’ is ignored # # Each option is specifiedon a separate line, as follows: # <fluency option name> = <fluencyoption value>[newline]For example, the following options file would set up the defaultusername and password for use with the Fluency development nodes:

# # Username and password for Fluency development nodes # username =guest password = fluency

The example below shows how to execute a simple Java program on Fluency:

public class HelloWorld {   public static void main(String args[ ])   {    System.out.println(“Hello World”);   } } # # Compile the programusing the native javac on the host machine # javac HelloWorld.java # #Execute the program on a Fluency node - assumes fluency.jar is in localdirectory # java -jar fluency.jar hostname=192.168.71.128 adminport=7100\   username=guest password=fluency HelloWorld # # The output from theFluency node and the application # INFO: JVM remote debugger agentrunning on [192.168.71.128:50276] ... Listening for transport dt_socketat address: 50276 Hello World

The Fluency SDK may ship with a VMWare image that contains a completeFluency server development environment. The server development appliancemay have the following nodes installed and configured:

-   -   primary—Fluency application node    -   backup—Fluency application node    -   replica—Fluency application node    -   domain manager—Distributed domain management    -   manager—Manager web interface

When the VMWare image is started all of these nodes are automaticallystarted and configured. To restart the server development appliance, theVMWare image should be powered off and back on. This will restore allnodes to their default configuration. The server development applianceis reset to its default state when the VMWare image is restarted. Anymodifications made to the server are discarded.

All user visible directories for the server development appliance areavailable in this path. They are also remotely mountable using SMB.

/opt/kabira/run/fluency-dev

Under this path are the following directories:

-   -   configuration—default and auto-load configuration files    -   deploy—user deployment directory for JAR and class files    -   html—generated HTML files for VMWare web pages    -   logs—event, console, and change log files    -   nodes—node directories        The configuration directory contains the following configuration        files:    -   default node configuration files    -   auto-load configuration files for Fluency application nodes        The structure of the configuration directory is:

configuration/<node name>

The Fluency application nodes—primary, backup, and replica have asubdirectory named autoconfigure. This directory is used for automaticconfiguration file loading.

To automatically load configuration files the following needs to happen.Configuration files to auto-load are copied into the application nodeautoconfigure directory, and the deployment tool autoconfigure parameteris set to true. When an application is loaded into a node for executionwith the autoconfigure parameter set to true, any configuration files inthe autoconfigure directory are loaded into the node and activated. Whenthe application exits, the configuration files are deactivated andremoved from the node.

Configuration files in the autoconfigure directory are loaded andactivated in ascending sort order based on the numeric value of thecharacters in the file name using the current character set. They aredeactivated and removed in the opposite order.

The deploy directory provides a location for installing JAR or classfiles on the server. When a JVM is started on an application node, anyJAR or class files in this directory are automatically added to theJVM's class path. The JAR files are sorted in ascending ASCII order byname before being added to the JVM's class path. This provides a simplemechanism for installing software on the server that is visible to theapplication nodes configured in the server development appliance.

The logs directory contains the following log files:

-   -   node specific event logs    -   console log    -   changelogs        The node specific event logs use the following naming        convention:

# # nodename - node name generating log file # mmdd - month/day stamp #count - number of files created on same date #<nodename>_<mmdd>_<count>.logThe console log is named console.log. It contains all the outputcaptured during node startup. Change logs are located in the change logs directory in the logs directory. They use the following namingconvention:

# # In Progress Files # # nodename - node name generating change logfile # mmdd - month/day stamp # count - number of files created on samedate changelogs/<nodename>/<mmdd>_<count>.xml # # Completed Files # #nodename - node name generating change log file # originalname -original name of file # count - number of files created on same datechangelogs/<nodename>/complete/<originalname>.xml_<count>

The nodes directory contains the runtime files associated with activenodes. Each active node is in a separate sub-directory. This directorycontains the shared memory files associated with a node and low-levellog files that may be useful for debugging problems.

We now describe default configuration information loaded into theDevelopment Appliance.

configuration “ha” version “1.0” type “ha” {   configure ha   {     //    // Configure a primary, backup, and replica node     //    NodeConfiguration { name = “primary”; };     NodeConfiguration {name = “backup”; };     NodeConfiguration { name = “replica”; };     //    // Define a single partition     //     PartitionConfiguration     {      name = “fluency”;       group = “fluency”;       primaryNodeName =“primary”;       backupNodeName = “backup”;       minimumNumber = 0;      maximumNumber = 100;       changeLogScope = LogBoth;      fileNameTemplate = “../../logs/changelogs/%nodeName/      %m%d_%count.xml”;       fileOpenMode = Append;      directoryCreateMode = “0755”;       fileCreateMode = “0666”;      rolloverBySize = Disabled;       rolloverSizeBytes = 0;      rolloverByInterval = Disabled;       rolloverIntervalSeconds = 0;      rolloverByNumRecords = Enabled;       rolloverNumRecords = 1000;      renameOnClose = Enabled;       renameTemplate =“../../logs/changelogs/%nodeName/complete/%m%d_%count.xml”;      loggingMode = Synchronous;       transactionalLogger = Enabled;      fileSyncMode = Unsynchronized;     };   }; };

This is the default security configuration.

configuration “users” version “1.0” type “security” {   configuresecurity   {     configure Principals     {       Principal       {        name = “guest”;         textCredential = “fluency”;        roles =         {           “switchadmin”,           “nodeAdmin”        };       };     };   }; }

This is the default domain configuration.

configuration “kdm” version “2.0” type “kdm” {   configure kdm   {    DomainConfig     {       //       // Domain name       //      domainName = “Fluency Development”;       //       // The numberof seconds between retrying       // queued configuration commandsfollowing a       // failure.       //       retryIntervalSeconds = 5;      //       // Optional manually configured managed nodes       //      nodeConfiguration = { };       //       // Optional configurationfor managed nodes       //       defaultNodeConfiguration = { };      //       // Configure the cluster group       //      groupConfiguration =       {         {           name =“Application Cluster”;           properties = “”;          defaultNodeConfiguration = { };         }       };     };   };};

This is the default node configuration.

configuration “nodeconfig” version “1.0” type “nodeconfig” {   configureswitchadmin     {     configure Node       {       //       // Defaultdescription for application node       //       Description       {        defaultDescription = “Fluency Development”;         properties ={ };       };       //       // This application node will automatically      // join the Application Cluster in the       // FluencyDevelopment domain       //       Domain       {         name = “FluencyDevelopment”;         group = “Application Cluster”;       };     };  }; };

The Java Debug Wire Protocol (JDWP) is used to integrate debuggingtools. JDWP was updated to support transactions. The transaction supportmakes assumptions on how a debugger client manipulates threads. Theseassumptions may not be true for all clients. In this case, the wrongtransaction, or worse a committed transaction, may be used by the JDWPin the Fluency JYIVI. This will cause unpredictable results whendebugging an application. A property was added to enable and disableJDWP transaction support.

-   -   −Djava.jdwp.transaction˜[trueIfa1se]

The default value of the java.jdwp.transaction property is true.Debugger clients who experience problems with JDWP when debuggingtransactional threads should change the value of this property to false.

-   -   vmOptions=−Djavajdwp transaction=false        Once disabled, transactional access to Managed Object fields        from a debugger client will only report the contents of the Java        proxy instance, not the backing shared memory.

The Fluency Class Loader uses multiple mechanisms to resolve a classreference. These mechanisms are searched in the following order:

-   -   1. Fluency defined system CLASS PATH    -   2. JAR or Class files in deploy directory    -   3. Client side CLASS PATH definition

Once a class is resolved the search is terminated. Fluency defines asystem CLASS PATH that cannot be changed. The contents of the deploydirectory are then searched to resolve class resolutions as describedabove. Finally, the CLASS PATH specified to the deployment tool issearched.

We have described a system and method in which a user can specifyuser-defined business logic of a desired transaction processingapplication using a platform-independent language such as JAVA, eventhough JAVA (and other platform-independent languages) typically doesnot support fully-transactional applications. For example, a JAVAVirtual Machine may be interfaced to a transaction processing platform.Thus, for example, a transaction processing platform may be configuredto execute instantiated service adaptors arranged to accomplish thebusiness logic, provided in JAVA, in conjunction with generictransaction processing logic. The transaction processing platform mayutilize a type system, and the type system utilized by the transactionprocessing platform may be exposed to the JAVA code using JAVA bindings,such as using a simple programming model to specify a JAVA class as amanaged object. As a result, when executed, the user-defined businesslogic specified in JAVA and executed by a JAVA Virtual Machine (whichmay be, for example, a fully-certified JAVA Virtual Machine), enjoys allof the transaction processing features of the underlying transactionprocessing platform.

The methods described herein may be carried out by computing devices,such as the computing nodes described herein, executing computer programinstructions from one or more memories and/or other tangiblecomputer-readable medium (and the one or more memories and/or othertangible computer-readable medium may comprise a computer programproduct.

1. A computing system, comprising: at least one computing deviceconfigured to execute computer program instructions to accomplish afully transactional application, including managed objects, wherein: themanaged objects are persisted in a shared memory of the computingsystem, such that a scope of the objects is global to the transactionalapplication; and operations on the managed objects are restricted tobeing carried out with respect to a transaction being processed by thefully transactional application.
 2. The computing system of claim 1,wherein: the managed objects are JAVA objects configured to bedistributed such that the managed JAVA objects are accessible from atleast one JAVA Virtual Machine (JVM).
 3. The computing system of claim2, wherein: the managed distributed JAVA objects are configured to beaccessible across all the instances of the JVM
 4. The computing systemof claim 2, wherein: the managed Java objects are configured to beexecuted by a plurality of nodes of a domain; and the managed Javaobjects are configured to be transactionally mirrored from a first nodeof the plurality of nodes to a backup node of the plurality of nodes. 5.The computing system of claim 4, wherein: the managed Java objects haveassociated timers via which transaction deadlocks are detectable.
 6. Thecomputing system of claim 5, wherein: the system is further configuredto, for detected transaction deadlocks, roll back the detecteddeadlocked transactions.
 7. The computing system of claim 6, wherein:rolling back a detected deadlocked transaction includes returningobjects, that were modified by the detected deadlocked transactions, toa state of those objects just prior to the detected deadlockedtransaction.
 8. The computing system of claim 1, wherein: the system isfurther configured to, for an object being read and then set, promote aread lock operable during the read operation to a write lock operableduring the write operation.
 9. The computing system of claim 1, wherein:the system is further configured to, for an object being read, togenerate a write lock on that object without generating a read lock onthat object.
 10. The computing system of claim 4, wherein: the system isfurther configured to manage a Java object of a distributedtransactional application across multiple nodes by coordinating theoperation of the nodes such that the Java object is consistently treatedon the multiple nodes.
 11. The computing system of claim 9, wherein: theJava object being consistently treated on the multiple nodes includestreating the object, across nodes, in a transactional manner.
 12. Thecomputing system of claim 1, wherein: the system is configured such thatwhen multiple transactions attempt to promote a read lock on the sameobject, all of the multiple transactions but one will generate apromotion deadlock for that object; and the promotion deadlock causesthe transaction to rollback, dropping read locks on that object.
 13. Thecomputing system of claim 12, wherein: the system is further configuredto replay each rolled back transaction, causing the rolled backtransactions to reacquire the locks on that object.
 14. A computerprogram product comprising at least one tangible computer readablemedium having computer program instructions tangibly embodied thereon,the computer program instructions to configure a computing systemcomprising at least one computing device to: accomplish a fullytransactional application, including managed objects, including:persisting the managed objects in a shared memory of the computingsystem, such that a scope of the objects is global to the transactionalapplication; and restricting operations on the managed objects to beingcarried out with respect to a transaction being processed by the fullytransactional application.
 15. The computer program product of claim 14,wherein: the computer program instructions are such that the managedobjects are JAVA objects configured to be distributed such that themanaged JAVA objects are accessible from at least one JAVA VirtualMachine (JVM).
 16. The computer program product of claim 15, wherein:the computer program instructions are such that the managed distributedJAVA objects are configured to be accessible across all the instances ofthe JVM
 17. The computer program product of claim 15, wherein: thecomputer program instructions are such that the managed Java objects areconfigured to be executed by a plurality of nodes of a domain; and thecomputer program instructions are such that the managed Java objects areconfigured to be transactionally mirrored from a first node of theplurality of nodes to a backup node of the plurality of nodes.
 18. Thecomputer program product of claim 17, wherein: the computer programinstructions are such that the managed Java objects have associatedtimers via which transaction deadlocks are detectable.
 19. The computerprogram product of claim 18, wherein: the computer program instructionsare further to configure the computing system to, for detectedtransaction deadlocks, roll back the detected deadlocked transactions.20. The computer program product of claim 19, wherein: rolling back adetected deadlocked transaction includes returning objects, that weremodified by the detected deadlocked transactions, to a state of thoseobjects just prior to the detected deadlocked transaction.
 21. Thecomputer program product of claim 14, wherein: the computer programinstructions are further to configure the computing system to, for anobject being read and then set, promote a read lock operable during theread operation to a write lock operable during the write operation. 22.The computer program product of claim 14, wherein: the computer programinstructions are further to configure the computing system to, for anobject being read, to generate a write lock on that object withoutgenerating a read lock on that object.
 23. The computer program productof claim 17, wherein: the computer program instructions are further toconfigure the computing system to manage a Java object of a distributedtransactional application across multiple nodes by coordinating theoperation of the nodes such that the Java object is consistently treatedon the multiple nodes.
 24. The computer program product of claim 19,wherein: the Java object being consistently treated on the multiplenodes includes treating the object, across nodes, in a transactionalmanner.
 25. The computer program product of claim 14, wherein: thecomputer program instructions are further to configure the computingsystem such that when multiple transactions attempt to promote a readlock on the same object, all of the multiple transactions but one willgenerate a promotion deadlock for that object; and the promotiondeadlock causes the transaction to rollback, dropping read locks on thatobject.
 26. The computer program product of claim 25, wherein: thecomputer program instructions are further to configure the computingsystem to replay each rolled back transaction, causing the rolled backtransactions to reacquire the locks on that object.